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Abstract 


CL  is  a  composition  language  for  predictable  assembly  from  certifiable  components.  An 
application  assembly  process  is  predictable  if  the  runtime  behavior  of  an  assembly  of 
components  can  be  predicted  from  known  properties  of  components  and  their  patterns  of 
interaction.  CL  is  similar  to  other  composition  languages  that  combine  a  component  and 
connector  style  of  description  with  a  core  compositional  semantics  specified  in  a  process 
algebra.  CL  differs  from  these  in  its  explicit  treatment  of  details  that  are  usually  abstracted 
or  ignored.  For  example,  CL  makes  explicit  the  allocation  of  execution  threads  to  component 
behavior;  this  distinguishes  concurrent  from  sequential  behavior,  and  leads  to  potentially 
smaller  state  spaces  as  well  as  more  accurate  behavioral  descriptions. 

This  report  describes  the  main  concepts  of  CL  and  its  rudimentary  graphical  syntax.  This 
report  also  defines  and  illustrates  the  compositional  semantics  for  CL  using  Hoare’s  CSP.  The 
twin  objectives  of  this  report  are  to  consolidate  our  current  thinking  about  an  ideal  CL  and 
to  provide  a  starting  point  for  the  design  of  a  practical  and  implementable  CL.  This  report 
closes  with  a  discussion  of  several  open  issues  that  must  be  resolved  before  this  second 
objective  can  be  satisfied. 
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1  Introduction 


Software  component  technology  emerged  in  the  late  1990s  as  a  promising  means  of 
simplifying  the  development  of  software  applications.  This  simplification  is  achieved  by 
imposing  constraints,  in  the  form  of  a  component  model  on  component  and  application 
developers.  A  component  model  specifies  a  set  of  component  types  and  rules  for  how  different 
component  types  can  interact.  Component  life-cycle  management  and  other  runtime  services 
are  provided  by  a  component  execution  environment,  often  called  a  container.  Component 
technology  shifts  the  emphasis  from  developing  new  code  to  integrating  or,  more  stylishly  if 
not  more  accurately,  composing  existing  software  components  in  accordance  with  a 
component  model. 

Application  development  has  indeed  been  simplified  by  component  models  and  containers  (in 
effect,  component  standards ),  but  they  apply  almost  exclusively  to  the  syntactic  or 
constructive  aspects  of  composition,  with  the  benefits  typical  of  standard  interfaces  and 
interaction  protocols.  What  has  yet  to  be  adequately  addressed  is  the  semantic  or  behavioral 
aspects  of  composition — how  will  a  composite  behave  at  runtime?  Will  it  meet  deadline, 
availability,  safety,  and  security  requirements? 


1 .1  Predictable  Assembly  from  Certifiable 
Components 

The  Software  Engineering  Institute's  (SETs)  Predictable  Assembly  from  Certifiable 
Components  (PACC)  Initiative  is  addressing  these  behavioral  aspects  of  composition.  In  this 
report,  the  term  assembly  will  be  used  synonymously  with  the  terms  composition  and 
composite.  In  our  vocabulary,  predictable  assembly  means  that  the  runtime  behavior  of  an 
assembly  of  components  can  be  predicted  from  the  properties  of  the  components  and  their 
patterns  of  interaction.  Further,  components  are  certifiable  if  their  properties  can  be 
ascertained  and/or  validated  by  disinterested  third  parties. 

The  following  sections  outline  the  key  aspects  of  our  overall  approach  to  PACC  and  establish 
the  context  for  the  composition  language  CL. 

1 .1 .1  Prediction-Enabled  Component  Technology 

Our  technical  approach  to  PACC  is  to  extend  component  technology  with  analysis 
technologies  that  support  compositional  reasoning ,  as  entailed  by  our  definition  of  predictable 
assembly.  We  call  such  an  extension  a  prediction- enabled  component  technology  (PECT).  A 
PECT  guarantees  that  assemblies  are,  by  construction,  predictable  with  respect  to  a  selected 
set  of  runtime  properties.  Figure  1  depicts  the  fundamental  idea  of  PECT  and  provides  a 
framework  to  introduce  PECT  concepts  and  terminology. 

The  PECT  component  model  defines  assembly  rules  that  are  concerned  exclusively  with  the 
constructive  or  syntactic  aspects  of  composition;  the  Constructive  Assembly  in  Figure  1  has 
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Figure  1:  Interpretations  Between  Constructive  and  Analysis  Views 


been  composed  in  accordance  with  this  component  model.  Associated  with  each  constructive 
assembly  is  one  or  more  analysis  views:  latency,  safety,  and  availability.  Each  analysis  view 
can  be  thought  of  as  input  to  a  particular  compositional  reasoning  technique.  Analysis  views 
are  automatically  derived  from  constructive  views  by  means  of  a  syntactic  transformation, 
called  an  interpretation.  Three  interpretations  are  depicted  in  Figure  1:  Ilatency ,  Isafety > 
and  I  avail- 

Interpretation  may  impose  constraints  on  constructive  assemblies  beyond  those  found  in  the 
component  model;  these  constraints  take  two  forms.  The  first  form  is  that  specific  component 
properties  might  be  required.  For  example,  Ilatency  might  require  that  components  have 
an  associated  property  that  describes  their  execution  time  or  the  scheduling  priorities 
assigned  to  any  independent  threads  within  the  component.  The  second  form  is  topological 
constraints.  Continuing  with  this  example,  Ilatency  might  disallow  any  topology  that  does 
not  enforce  the  priority  ceiling  protocol,  that  is,  where  the  priority  of  a  server  is  at  least  as 
high  as  the  highest  priority  of  any  of  its  clients. 

An  interpretation  is  consistent  if  each  constructive  assembly  is  related  to  at  most  one 
analytic  view  under  that  interpretation.  An  interpretation  is  valid  if  there  is  empirical  or 
formal  justification  for  the  claim  that  behaviors  predicted  in  the  analytic  view  will  be 
manifested  by  the  assembly  of  components  specified  in  the  constructive  view. 

1 .1 .2  CL:  A  Core  Composition  Language  for  PECT 

The  analogy  between  component  models  and  programming  languages  is  quite  natural.  In  the 
former  case,  we  are  concerned  with  the  well  formedness  of  assemblies  with  respect  to 
construction  rules  and  one  or  more  interpretations;  in  the  latter  case,  we  are  concerned  with 
the  well  formedness  of  programs  with  respect  to  a  syntax  and  associated  type  theory.  Each 
analysis  view  in  Figure  1  reflects  some  theory  about  the  runtime  behavior  of  an  assembly;  no 
less  is  true  of  type  systems.  Type  systems  guarantee,  by  rules  of  syntax,  the  absence  of 
certain  classes  of  runtime  behavior  [Cardelli  97].  PECT  guarantees,  by  rules  of  syntax,  the 
analyzability  of  certain  classes  of  runtime  behavior. 

The  strength  of  this  analogy  and  our  own  experience  in  building  PECTs  strongly  motivate 
the  need  for  a  composition  language,  which  we  denote  CL.  CL  gives  formal  meaning  to  a 
PECT  component  model — each  constructive  assembly  is  a  sentence  in  the  language  of  CL. 
The  major  syntactic  elements  of  CL  are  components  and  connectors ,  something  that  CL  has 


2 


CMU/SEI-2002-TN-026 


in  common  with  most  architecture  description  languages  (ADLs).  An  annotation  mechanism 
allows  us  to  attach  ( property ,  value }  pairs  to  components  and  connectors,  and  to  finer-grained 
syntactic  elements  of  CL.  The  values  of  these  properties  can  be  used  to  construct 
analysis-specific  interpretations.  Thus,  CL  is  a  core  which  can  be  extended  with  one  or  more 
analysis  technologies,  each  of  which  imposes  additional  behavioral  semantics  on  CL. 

1.1.3  CL:  Built-In  Composition  Semantics 

One  behavioral  semantics  is  fundamental  to  the  meaning  of  many  interpretations  and  so  is 
incorporated  into  the  core  CL.  The  semantics  of  component  and  interaction 
behavior— specifiable  in  a  number  of  process  algebras,  notably  CSP  [Hoare  85],  CCS 
[Milner  89],  7r-Calculus  [Milner  99],  and,  more  recently,  FSP  [Magee  01] — must  be  common  to 
every  interpretation. 

While  various  ADLs  [Magee  93,  Allen  97]  and  self-described  composition  languages 
[Achermann  02]  have  also  combined  component  and  connector  syntax  with  process  algebraic 
semantics,  CL  differs  by  treating  software  components  as  implementations  rather  than  as 
design  abstractions.  For  example,  CL  preserves  the  asymmetry  of  the  caller  and  callee; 
distinguishes  asynchronous,  synchronous,  and  reentrant  behavior;  and  makes  explicit  the 
allocation  of  threads  of  control  to  component  behavior.  These  and  other  “implementation 
details”  often  have  a  profound  impact  on  assembly  behavior. 

These  details  also  complicate  composition  semantics,  that  is,  how  assembly  behavior  is 
composed  from  component  behavior  specified  in  CSP.  On  the  other  hand,  these  details  also 
offer  opportunities  to  reduce  the  size  of  the  composed  state  space,  for  example,  by  avoiding 
unnecessary  parallel  composition  where  concurrent  behavior  is  impossible.  This,  we  hope, 
will  have  positive  ramifications  on  the  tractability  of  model  checking  in  PECT. 

1.1.4  CL:  Environment-Specific  Connectors 

In  CL,  the  semantics  of  connectors  is  defined  with  respect  to  specific  environment  types.  For 
example,  an  asynchronous  message  queue  in  a  real-time  environment  might  implement  a 
small  circular  buffer  with  overwrite,  while  a  non-real-time  environment  might  implement 
(effectively)  unbounded  buffers  with  no  overwrite. 

In  CL,  the  behavior  of  connectors  is  modeled  separately  from  that  of  components,  and 
connectors  define  the  composition  semantics  of  CL.  Composition  in  CL  always  takes  place  in 
the  context  of  an  environment  type,  and  each  environment  type  defines  a  set  of  connectors 
that  are  valid  within  that  environment  type.  Composition  of  assemblies  across  heterogeneous 
environment  types  is  handled  by  explicitly  modeling  the  shared  environment  type  and  the 
bridging  connectors  it  defines. 

Specifications  of  connectors  are  not  trivial  and  can  be  simplified  using  specification  patterns. 
One  objective  of  this  report  is  to  produce  a  general  approach  for  specifying  the  composition 
semantics  for  arbitrary  interaction  schemes  (connectors)  for  arbitrary  environment  types  E. 
We  hasten  to  add  here  that  end  users  of  PECTs  never  see  these  semantic  complexities  any 
more  than  users  of  modern  programming  languages  see  the  complexity  of  type  checking  or 
code  generators. 


CMU/SEI-2002-TN-026 


3 


1.1.5  CL:  The  Pin  Style 

We  can  think  of  each  CL  configuration,  set  of  environment  types,  and  set  of  interpretations 
as  defining  a  distinct  composition  language  or  perhaps  a  distinct  family  of  composition 
languages.  Yet,  despite  the  variation  inherent  in  this  scheme,  each  configuration  shares  with 
all  others  a  single  unifying  constructive  metaphor:  the  Pin  Style  or,  more  simply,  Pin. 

In  Pin,  components  communicate  exclusively  through  their  pins:  components  receive  stimulus 
through  their  sink  pins  and  can  stimulate  other  components  through  their  source  pins.  No 
component  can  be  its  own  stimulus,  and  only  the  environment  can  be  an  originating  source  of 
stimuli  (another  aspect  of  the  definition  of  environment  types).  Therefore,  Pin  enforces  a 
model  of  pure  composition — an  application  is  defined  entirely  in  terms  of  a  set  of  components 
and  their  connections.  The  behavior  of  a  component  is  described  in  terms  of  reactions  that 
specify  the  stimulus-response  behavior  of  a  component  on  its  sink  and  source  pins. 

Connectors  are  used  to  link  the  source  pins  of  one  component  to  the  sink  pins  of  other 
components;  these  links  represent  the  ability  of  components  to  interact.  The  semantics  of 
connectors  define  how  two  or  more  component  reactions  are  composed  into  a  higher-order 
reaction.  Two  broad  classes  of  interactions,  and  therefore  connectors,  are  defined  in  Pin: 
asynchronous  and  synchronous.  Beyond  this,  most  of  the  semantic  details  of  connections,  for 
example  their  arity  (e.g..  2-ary  or  N-ary  connectors),  are  environment  specific. 

Before  we  proceed,  we  would  like  to  warn  the  reader  that  the  distinction  between  the  Pin 
architectural  style  and  the  CL  composition  language  is  not  always  clear.  The  Pin  style  deals 
with  concepts  such  as  components,  pins,  their  topologies,  and  so  forth;  CL  is  the  formal 
syntax  and  semantics  for  component  assemblies  documented  in  the  Pin  style.  CL  is  also  the 
language  in  which  the  precise  interaction  semantics  for  different  environment  types  are 
defined. 

Determining  which  concepts  belong  in  Pin  and  which  ones  belong  in  CL  is  not  always  an  easy 
decision.  For  example,  we  believe  that  the  distinction  between  synchronous  and  asynchronous 
pins  is  universal,  so  we  consider  that  distinction  part  of  Pin.  However,  the  queueing  semantics 
of  asynchronous  sink  pins  may  differ  among  environment  types  and  so  should  be  part  of  CL. 

Although  we  have  attempted  to  make  the  proper  distinctions  between  Pin  and  CL,  we  have 
not  always  been  successful,  primarily  because  we  are  still  exploring  the  issue  as  we  gain 
experience  with  defining  the  semantics  of  different  environment  types.  When  reading  Section 
3,  keep  in  mind  that  the  concepts  described  are  part  of  Pin,  while  the  syntax  used  in 
examples  is  part  of  CL. 

1 .2  About  This  Report 

1 .2.1  Objective  of  This  Report 

CL  and  its  underlying  Pin  metaphor  are  under  development;  this  report  is  a  snapshot  of  our 
thoughts  about  them.  Our  intent  is  to  both  consolidate  our  understanding  and  to  expose  the 
main  ideas  to  constructive  criticism. 
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The  primary  focus  of  this  report  is  on  the  specification  and  composition  of  component 
reactions  over  different  types  of  connectors.  Because  the  set  of  connector  types  and  hence 
their  semantics  is  open-ended,  our  long-term  objective  is  to  define  specification  patterns.  In 
this  way,  we  hope  to  reduce  the  complexity  involved  in  developing  PECTs  and,  perhaps,  to 
automate  some  of  the  more  tedious  aspects  of  this  development. 

The  secondary  focus  of  this  report  is  to  establish  preliminary  ideas  for  a  visual  and  textual 
language  of  CL.  One  premise  of  our  approach  to  PECT  is  that,  while  the  infrastructure  of  a 
PECT  might  be  quite  complex-comprising  as  it  does  different  interaction  schemes, 
interpretations,  and  behavioral  models-much  of  this  complexity  can  be  “packaged”  in 
high-level  notations  and  tools.  In  this  respect,  CL  and  its  supporting  language  environment 
requires  serious  attention  in  its  own  right. 


1 .2.2  Organization  of  This  Report 

We  first  provide  an  overview  of  related  work  in  Section  2  and  then  introduce  the  major 
features  of  CL  through  a  graphical  syntax  in  Section  3.  In  Section  4,  we  define  and  illustrate 
a  naive  composition  semantics  for  CL;  we  extend  this  definition  to  address  a  limited  form  of 
compositional  minimization  in  Section  5.  Examples  of  the  naive  semantics  are  provided  in 
Section  6.  The  open  issues  that  must  be  answered  before  CL  can  progress  from  its  interim 
status  are  discussed  briefly  in  Section  7.  Finally,  we  close  with  a  brief  discussion  of  directions 
for  further  work  in  Section  8.  In  the  appendix,  we  present  a  brief  summary  of  the  formal 
notations  used  in  this  report. 

1.2.3  Audience  for  This  Report 

This  report  is  targeted  to  computer  scientists  and  software  engineers  interested  in  the  formal 
specification  of  component-based  software  and  in  the  use  of  these  specifications  for 
automated  composition  and  compositional  reasoning.  Sections  2,  3,  7,  and  8  require  only 
general  familiarity  with  component-based  software  technology,  although  some  background  in 
ADLs  and  coordination  languages  would  be  helpful.  Sections  4-6,  however,  require  the  reader 
to  have  advanced  knowledge  of  CSP  [Hoare  85]. 

1 .2.4  How  to  Read  This  Report 

Readers  interested  in  an  overview  of  Pin  and  CL  should  read  Section  3,  the  preliminaries  of 
Section  4,  and  Section  7.  Readers  interested  in  comparing  Pin  and  CL  to  other  approaches 
should  also  include  Section  2.  Those  readers  interested  in  understanding  our  approach  to 
compositional  semantics  should  read  the  entire  report. 
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2  Related  Work 


There  has  been  substantial  research  under  the  general  headings  of  module  interconnection 
languages  (MILs),  architecture  description  languages  (ADLs),  coordination  languages,  and, 
more  recently,  composition  languages.  The  extent  to  which  these  headings  constitute  distinct 
or  overlapping  areas  of  investigation  is  largely  a  matter  of  perspective.  For  example,  one 
survey  classifies  Polylith  [Purtillo  94]  and  Rapide  [Luckham  95]  under  the  heading  of 
coordination  languages,  while  their  inventors  originally  classified  them  as  MILs  and  ADLs, 
respectively  [Papadopoulos  98]. 1  It  has  even  been  argued  that  composition  languages 
represent  an  amalgam  of  scripting,  ADLs,  and  coordination  languages  [Achermann  02]. 
Despite  some  terminological  confusion,  the  exemplars  of  these  categories  all  seem  similarly 
concerned  with  the  search  for  language  abstractions  and  semantics  that  address  issues  of 
complexity  that  are  not  conveniently  addressed  by  the  conventional  imperative  programming 
paradigm.  What  differs  is  only  the  type  of  complexity  addressed:  concurrency,  distribution, 
mobility,  and  so  forth.  Here,  we  refer  only  to  those  exemplars  that  most  closely  resemble,  or 
have  most  directly  influenced,  our  thinking  about  CL. 

Wright  is  an  ADL  best  known  for  formalizing  connectors  as  first-class  abstractions  [Allen  97]. 
Like  Wright,  CL  distinguishes  connectors  from  components  and  specifies  the  semantics  of 
connectors  in  CSP.  CL  and  Wright  are  also  similar  in  their  concern  for  representing  system 
structure  by  making  explicit  the  semantics  of  connectors  and  by  exposing  the  interface 
signature  of  access  points — ports  in  Wright,  pins  in  CL.  Unlike  Wright,  CL  does  not  make 
connectors  first-class  elements  of  the  language:  there  is  no  way  in  CL  itself  to  define  new 
types  of  connectors.  Whether  this  makes  CL  less  general  than  Wright  is  a  long-running 
argument  among  ADL  researchers.  Darwin  is  another  ADL  with  strong  similarities  to  CL 
that,  like  Wright,  has  influenced  the  design  of  CL  [Magee  93].  Darwin  specifies  component 
and  assembly  behavior  using  the  FSP  process  algebra,  which  is  more  limited  but 
substantially  simpler  than  CSP  [Magee  01].  Like  CL,  but  unlike  Wright,  Darwin  also  makes 
structurally  explicit  the  distinction  between  a  component’s  incoming  ( provides )  and  outgoing 
( requires )  interfaces.  However,  Darwin  is  more  concerned  with  behavior  than  with  system 
structure;  unlike  CL  or  Wright,  it  does  not  explicitly  represent  the  boundaries  and  interfaces 
of  deployed  components.  Koala  is  a  Darwin-based  development  environment,  in  industrial 
use,  for  developing  consumer  electronics  [van  Ommering  02].  Like  CL,  it  addresses 
implementation  issues  such  as  concurrency,  but  whereas  concurrency  is  addressed  in  CL 
composition  semantics,  in  Koala,  it  is  addressed  by  introducing  design  primitives  called 
thread  pumps  and  pump  engines .  Tracta  is  a  research  prototype,  also  based  on  Darwin 
[Giannakopoulou  99].  Tracta  is  a  toolkit  environment  for  applying  a  variety  of  compositional 
verification  techniques;  it  also  implements  a  variety  of  compositional  reduction  techniques  to 
ameliorate  state  space  explosion  under  model  checking.  In  many  respects,  we  are  aiming 
towards  a  Tracta-like  environment  with  CL.  We  generalize  from  Tracta  in  two  ways.  First, 
the  PECTs  we  construct  using  CL  (perhaps  more  accurately,  the  Pin  component  model) 
include  mechanisms  to  support  empirical  as  well  as  formal  analyses.  Second,  (although  this  is 
future  work)  we  plan  to  “compile”  CL  into  a  standard  intermediate  representation  such  as 

1  Although  the  authors  did  distinguish  MILs  and  ADLs  in  their  survey,  these  categories  were  subsumed  by 
the  coordination  languages  category. 
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Bandera  Intermediate  Representation  (BIR)  [Corbett  99];  the  intent  is  to  simplify  the 
integration  of  a  variety  of  existing  verification  technologies,  such  as  SMV  [Cimatti  00],  SPIN 
[Holzman  97],  and  FDR  [Roscoe  98],  into  a  PECT.  In  this  respect,  CL  is  similarly  motivated 
to  Acme  [Garlan  97],  an  ADL  interchange  language.  However,  while  Acme,  like  CL,  defines  a 
component  and  connector  syntax  and  an  annotation  mechanism,  it  does  not  define  a  base 
composition  semantics.  PECOS  is  a  component  model  for  field  devices  [Nierstrasz  02].  Like 
Wright  and  CL,  it  defines  both  components  and  connectors.  Like  CL  and  Acme,  PECOS 
provides  an  annotation  mechanism;  in  all  three,  the  annotations  are  used  to  provide  analysis 
and  tool-specific  information.  PECOS  also  specifies  component  behavior  formally,  although  it 
uses  petri  nets  in  preference  to  process  algebra.  PECOS  does  not  yet  make  use  of  petri  nets 
for  behavior  analysis,  although  there  are  plans  to  apply  it  to  timing  analysis.  Should  these 
plans  come  to  fruition,  PECOS  would  satisfy  our  definition  of  PECT.  Further,  PECOS  is 
specialized  to  memory-constrained  devices  and  has,  for  example,  a  built-in  cyclic  scheduler. 
Last,  Piccola  is  a  composition  language  that  combines  aspects  of  ADL  and  scripting 
[Achermann  02].  Like  CL  and  Wright,  Piccola  uses  a  process  algebra  to  specify  component 
and  assembly  behavior.  However,  instead  of  CSP,  it  uses  7r£-calculus,  a  form  of  Milner’s 
7r-calculus,  that  provides  a  polymorphic  extension  to  7rs  fixed  positional,  tuple-based 
interfaces  [Milner  99];  this  adds  considerable  expressive  power  to  the  language  at  the  cost  of 
some  increased  complexity.  Piccola  is  also  more  general  than  CL  in  that  it  is  not  restricted  to 
pure  composition:  the  scripting  language  embeds  considerable  application  semantics,  as  does 
a  glue  language  that  is  used  to  adapt  components  to  remove  mismatches  among  their 
interfaces  or  behaviors.  It  is  arguable  whether  this  more  general  focus  is  laudable  or 
necessary. 
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Overview  of  Pin 


3.1  Notational  Conventions 

In  the  following  discussion,  entities  are  denoted  by  their  names.  We  use  component  names  c;, 
sink  pin  names  Sj  (for  the  jth  stimulus),  and  source  pin  names  r*  (for  the  jth  response ), 
where  i,j,  k  >  0.  Where  the  distinction  between  sink  and  source  pin  is  irrelevant,  we  will  use 
pin  names  pk  (for  pm*,).  In  all  cases,  we  omit  subscripts  where  they  are  not  required. 
Components  define  a  scope  for  pin  names;  within  the  scope  of  a  component,  all  pin  names 
must  be  unique.  The  expression  c.p  denotes  pin  p  of  component  c.  We  use  capitalized  names 
to  denote  predicates  defined  on  pins.  For  example,  SomeCondition(c.p)  is  True  if  pin  c.p 
satisfies  SomeCondition  and  is  False  otherwise.  We  use  lowercase  names  to  denote  properties 
of  pins.  For  example,  someProperty(c.p)  denotes  the  value  of  property  someProperty  of  pin 
c.p. 

3.2  Components  and  Pins 

A  component  interacts  with  its  environment  exclusively  through  its  pins;  there  are  no  other 
communication  paths  to  or  from  a  component.  As  mentioned  in  1.1.5,  there  are  two  types  of 
pins:  sink  pins  and  source  pins.  A  component  receives  communication  (stimuli)  on  its  sink 
pins  and  initiates  communication  (responses)  on  its  source  pins.  Figure  2  depicts  the  graphic 
notation  we  use  and  refer  to  later.  By  convention,  we  put  sink  pins  on  the  left  side  of  a 
component  and  source  pins  on  the  right  side.  This  allows  us,  at  the  cost  of  some  cultural 
bias,  to  “read”  the  component,  and  sometimes  their  assemblies,  from  left  to  right. 


Figure  2:  Graphical  Notation  for  a  Component  and  Its  Pins 


3.3  Pin  Data  Interface 

Each  pin  has  a  data  interface ,  denoted  by  interface(c.p).  For  some  c.p,  interface(c.p) 
describes  the  type  (To  x  T\  x  •  •  •  x  T„),  where  each  Tj  is  the  primitive  data  type  transmitted 
on  the  pin  and  each  primitive  type  is  one  of 
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{ SByte ,  UByte,  SWord,  UWord,  SDWord,  UDWord ,  SDouble,  Float,  String}.  A  complete 
specification  of  CL  for  a  particular  environment  would  specify  the  representation  of  these 
types;  we  do  not  do  so  here. 

As  in  conventional  interface  specification,  each  data  type  corresponds  to  a  formal  argument 
that  has  a  parameter-passing  mode,  where  mode  is  one  of  {/n,  Out ,  InOut}.  Note  that  a  pin’s 
data  type  interface  might  be  specified  explicitly  or  be  inferred  from  a  CSP  specification.  This 
issue  remains  open. 

3.4  Source  Pins 

There  are  two  types  of  source  pin-asynchronous  and  synchronous-that  satisfy  the  predicates 
Asynchronous(c.p)  and  Synchronous(c.p ),  respectively.2  Source  pins  represent  the  ability  of 
a  component  to  initiate,  in  response  to  some  original  stimulus,  an  interaction  with  other 
components. 

It  is  reasonable  to  think  of  asynchronous  source  pins  as  message  sends  and  synchronous  source 
pins  as  procedure  calls,  but  too  much  faith  should  not  be  put  on  this  gross  interpretation,  as 
we  have  not  always  implemented  asynchronous  connectors  in  this  way.  Nonetheless, 
arguments  in  an  asynchronous  pin  data  interface  are  restricted  to  mode  In.  Source  pins  are 
graphically  denoted  with  pin  heads  >  if  Asynchronous  (c.r)  and  >  if  Synchronous  (c.r).  In 
Figure  2,  c.ri  is  an  asynchronous  source  pin,  and  c.r 2  is  a  synchronous  source  pin. 

If  Optional(c.r),  then  c.r  is  an  optional  source  pin,  otherwise  it  is  mandatory.  Mandatory 
source  pins  must  be  connected  in  an  assembly,  while  optional  source  pins  need  not  be 
connected.  This  models  the  distinction  between  calls  (optional)  and  uses  (mandatory), 
respectively.  A  component  Cq  uses  sink  pin  Ci.s  if  the  behavior  of  cq  depends  on  the  correct 
behavior  of  ci.s:  otherwise  it  only  calls  C\.s.  Graphically,  we  distinguish  optional  source  pins 
from  mandatory  ones  by  enclosing  the  names  of  optional  sources  in  braces  [  ].  So,  c.[r2]  is  an 
optional  source  pin  in  Figure  2. 

3.5  Sink  Pins 

There  are  two  types  of  sink  pins,  asynchronous  and  synchronous.  Analogously  with  source 
pins,  they  represent  the  ability  of  a  component  to  receive  asynchronous  or  synchronous 
stimulus,  respectively.  As  with  source  pins,  the  data  type  interface  of  an  asynchronous  sink 
pin  is  restricted  to  arguments  of  mode  In.  Sink  pins  are  graphically  denoted  with  pin  heads 
if  Asynchronous(c.s)  and  >  if  Synchronous(c.s).  In  Figure  2,  c.si  is  asynchronous,  while 
{c.Sjc  |  2  <  k  <  6}  are  synchronous. 

If  Threaded (c.s),  c.s  has  its  own  thread  of  control,  and  threadld(c.s)  denotes  its  identity. 
Threads  represent  units  of  concurrent  execution  and  may  be  implemented  by  operating 
system  threads,  processes,  tasks,  and  so  forth.  Graphically,  tj  =  threadld(c.s)  is  denoted  as  a 
suffix  :  tj  on  the  sink  pin  name.  In  Figure  2,  sink  pins  C.S2  and  C.S3  are  unthreaded,  but  c.s5 

2  Currently,  A  synchronous (x)  &  -> Synchronous  (x),  but  it  seems  more  flexible,  if  verbose,  to  define  two 
predicates  rather  than  just  one.  This  is  true  of  other  predicates  as  well. 


10 


CMU/SEI-2002-TN-026 


has  the  thread  threadld(c.s 5)  =  £3.  Threads  may  be  shared  by  sink  pins.  So,  in  Figure  2,  c.s$ 
and  c.s$  share  thread  £3,  but  c.S\  and  C.S4  have  their  own  threads.  Note  that  asynchronous 
sink  pins  must  be  threaded,  that  is,  Asynchronous(c.s)  =>  Threaded (c.s). 

If  Mutex  (c.s),  c.s  is  called  a  mutex  sink,  and  only  one  caller  may  be  active  on  c.s  at  any 
given  time;  in  effect,  the  caller  must  obtain  the  semaphore  for  c.s.  Conversely,  if 
-^Mutex(c.s),  the  c.s  is  called  a  reentrant  sink  and  is  never  guarded  by  a  semaphore.  Note 
that  even  a  reentrant  c.s  might  force  a  caller  to  wait  while  it  synchronizes  on  an  internal  (to 
c.s)  resource.  We  obviously  care  about  this  property  only  for  synchronous  sink  pins,  since 
asynchronous  callers  do  not  wait  and  cannot  be  blocked.  Graphically,  mutex  sinks  are 
represented  with  the  pin  head  >|.  In  Figure  2,  Mutex(c.Sj),  3  <  k  <  6.  Note  that 
Threaded(c.s)  A  -1 A  synchronous  (c.s)  =>  Mutex(c.s). 


3.6  Assemblies  and  Environments 


An  assembly  is  defined  as  a  set  of  components  and  their  connections.  We  denote  an  assembly 
as  aj.  An  assembly  is  graphically  depicted  as  a  box  enclosing  a  set  of  connected  components; 
this  visually  reinforces  the  notion  of  an  assembly  as  a  scope  of,  or  container  for,  components. 
Thus,  a.c  denotes  component  c  in  the  scope  of  assembly  a.  Figure  3  depicts  a  simple 
assembly  to  illustrate  key  points  in  the  following  discussion. 

A  connection,  or  connector,  is  established  between  two  components  when  some  source  pin  ca.r 
is  connected  to  some  sink  pin  Cj.s,  i  ^  j  (this  inequality  is  assumed  in  further  discussion).  In 
text,  we  denote  the  connection  as  c*.r  Cj.s.  Components  c,  and  Cj  must  be  contained  by 
the  same  assembly  if  they  are  to  be  composed.  A  connection  c*.r  ^  Cj.s  also  requires  that 
C{.r  and  cj.s  be  mutually  conformant.  The  rule  for  mutual  conformance  is  simple:  both  pins 
must  be  synchronous,  or  both  must  be  asynchronous,  and  their  data  interfaces  must  have  the 
same  argument  types,  modes,  and  positions.  Graphically,  we  denote  a  connection  as  a 
double-headed  lollipop,  with  the  lollipop  heads  circumscribing  the  connected  pins. 


assembly  name  environment  type 

Figure  3:  Graphical  Notation  for  an  Assembly 


Each  assembly  has  an  associated  environment  type,  which  is  denoted  by  the  :  Ej  suffix  of  an 
assembly  name.  Environment  types  play  two  crucial  roles  in  Pin. 
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First,  they  define  the  services,  specified  as  sink  and  source  pins,  that  components  may  use. 
Graphically,  these  services  are  attached  to  the  assembly  by  means  of  environment  junctions, 
drawn  as  small  black  boxes.  For  example,  in  Figure  3,  a  runtime  environment  associated  with 
assembly  ao  provides  two  services:  the  source  pin  CLOCK  and  the  sink  pin  CONSOLE. 
These  services  can  be  thought  of  as  being  implemented  by  an  environment-provided 
component  with  a  single  sink  pin  (a0.  CONSOLE)  and  source  pin  [a®.  CLOCK). 

We  denote  a  connection  with  an  environment  service  in  an  analogous  way  to  that  defined 
earlier,  that  is,  as  a®. CLOCK  ao-co-si,  and  ao.c3.r1  oq. CONSOLE.  To  make  these 
expressions  easier  to  read,  we  allow  assembly  names  to  distribute  over  so,  instead  of  the 
above,  we  could  write  ao  (CLOCK  c0.si)  and  00(03.^  CONSOLE).  If  the  scope  of  a0  is 
understood,  we  often  omit  it  altogether. 

Second,  environment  types  supply  the  interaction  models  implemented  by  connectors.  For 
example,  consider  the  interaction  topology  in  Figure  3,  which  includes 

•  ao(CLOCK  ~>co.Si),  ao(c3.ri  CONSOLE ),  and  ao(c2.r2  C0.S2) 

•  co-r  {ci-s,  C2-s} 

•  {ci.r,  c2.n}  c3.s 

where  we  use  sets  {c.pi,  c.p2, ...}  to  denote  multiple  sinks  and  sources  on  1  :N  and  N  :  1 
compositions,  respectively.  The  semantics  of  the  1:1  composition  in  the  first  bullet  is  likely 
to  be  intuitively  clear,  but  what  about  the  1 :  N  asynchronous  composition  in  the  second 
bullet?  Does  co-r  {cj  .,s.  C2 . s }  specify  one  or  two  connectors?  Does  this  represent  a 
broadcast  or  a  sequence  of  unicasts?  If  it’s  a  sequence,  what  is  the  order?  What  is  the 
semantics  of  message  buffering— FIFO  or  LIFO?  What  is  the  capacity  of  the  message  buffers? 
Analogously,  what  is  the  interaction  order  of  the  N :  1  synchronous  composition  in  the  third 
bullet?  We  may  want  different  answers  to  these  questions  in  different  component  runtimes, 
and  these  different  answers  will  result  in  different  connector  semantics.  So,  connectors  are 
always  defined  with  respect  to  some  environment  type. 


3.7  Behavior:  Reaction  and  Interaction 

So  far,  we  have  focused  on  the  syntax  of  composition.  This  makes  sense,  since  we  have  largely 
been  discussing  constructive  assemblies  that  are  concerned  with  enabling  runtime  interactions 
rather  than  their  behavior.  Informally,  Pin  gives  us  the  vocabulary  to  describe  the  structure 
of  an  assembly  (i.e.,  the  topology  of  the  components  and  pins),  while  the  compositional 
reasoning  associated  with  analysis  views  describe  what  the  assembly  does  at  runtime.  We  say 
that  CL  is  semantically  extensible  since  different  syntactic  elements  of  CL — the  language  for 
documenting  architectures  in  the  Pin  style — may  be  annotated  with  information  that  is  used 
to  construct,  via  interpretations,  additional  semantics  for  each  assembly  in  the  Pin  style. 

However,  one  behavioral  semantics  is  fundamental  to  the  meaning  of  many  interpretations 
and  so  is  incorporated  into  the  core  CL.  Component  and  interaction  behavior  specifiable  in  a 
process  algebra  such  as  CSP  [Hoare  85],  CCS  [Milner  89],  7r-Calculus  [Milner  99],  or  FSP 
[Magee  01]  must  be  common  to  every  interpretation.  We  have  elected  to  use  CSP  as  the 
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behavior  specification  language  for  CL.  In  this  section,  we  describe  only  the  essence  of 
component  behavior  and  its  composition;  the  details  are  provided  in  Section  4.  We  treat  the 
specification  of  component  behavior  first  and  then  turn  to  composition  behavior. 

3.7.1  Component  Behavior:  Reactions 

Components  have  intrinsic  behavior:  they  are,  after  all,  implementations.  We  model  the 
behavior  of  a  component  in  terms  of  reactions.  A  reaction  is  a  CSP  process  that  relates  one 
or  more  sink  pins  to  one  or  more  source  pins,  indicating  how  the  component  reacts  to 
stimulation  of  its  sink  pins.  The  general  form  is  a  process  that  looks  something  like 
R  =  s  r  — >  R,  where  s  is  a  sink  pin  that  can  be  stimulated,  r  is  a  source  pin  that  is 
stimulated  in  response  to  a  stimulus  on  s,  and  R  is  the  CSP  process  that  describes  this 
pattern  of  behavior.  Note  that  because  reactions  are  defined  within  the  scope  of  a 
component,  we  omit  usual  scoping  notation  such  as  c.s,  c.r,  and  c.R. 

Reactions  reflect  the  thread  structure  of  a  component.  For  example,  all  behavior  implemented 
by  a  common  thread  is  modeled  as  a  single  reaction.  This  allows  analyses  to  take  into 
account  the  actual  degree  of  threading  and  potential  concurrency  errors  of  the  component 
implementation.  The  behavior  of  a  component  as  a  whole  is  specified  as  the  CSP  parallel  ||  or 
interleaved  |||  composition  of  its  reactions,  depending  on  which  better  models  the  actual 
interaction  among  the  component’s  threads.  The  gist  of  reaction  rules  is  depicted  in  Figure  4. 


Figure  4:  Reactions  Partitioning  the  Behavior  of  a  Component 

In  this  example,  there  are  three  reactions:  Rx,  R2,  and  R3.  The  ovals  are  used  to  illustrate 
which  pins  are  related  by  each  reaction:  for  example,  Ri  is  shown  as  relating  sink  pins  si  and 
s2  to  source  pins  ri  and  r2.  Ri  represents  the  behavior  of  a  single  thread  t  that  is  shared  by 
sinks  si  and  s2.  A  definition  of  R\  could  be  Ri  =  (si  ->•  r\  — >  R\)  □  (s2  ->  r2  -»  R\). 

Reactions  allow  us  to  specify  the  causal  dependencies  among  behaviors  in  an  assembly  of 
components.  The  most  basic  causal  dependency  is  the  dependency  chain,  as  illustrated  in  the 
above  reaction.  More  complex  behaviors,  such  as  coordination  among  reactions  or  changes  in 
behavior  based  on  accumulated  state  information,  can  also  be  modeled. 

3.7.2  Assembly  Behavior:  Interactions 

Up  to  this  point,  we  have  been  using  the  operator  in  an  informal  manner.  Although  we 
never  made  the  claim,  a  reasonable  inference  on  the  part  of  the  reader  would  be  that  has 


CMU/SEI-2002-TN-026 


13 


some  sort  of  composition  semantics.  We  need  more  detail  to  justify  this  inference  and  outline 
its  implications  for  understanding  the  behavior  of  assemblies,  or,  more  technically,  how 
component  behaviors  interact  when  composed  using 

A  simple  algebraic  model  of  composition  might  be  C  x  C  — »  (7,  where  we  take  C  to 
denote  the  set  of  all  components.  That  is,  C  is  the  carrier  for  an  algebra  with  a  single 
operator.  We  denote  this  simple  algebra  as  (<7,  ^).  To  give  a  concrete  example,  the  pipeline 
style  satisfies  this  model,  where  in  place  of  ((7,  ~>),  we  have  (P,  |)  >,  where  P  denotes  Unix 
processes  and  |  denotes  the  pipeline  connector  [Garlan  93]. 

However,  Pin  is  more  general  and  complex  than  the  simple  Unix  pipeline  model.  For 
example,  the  constructive  meaning  of  |  in  P\  \  P2  is  that  the  output  (stdout)  of  P\  is 
connected  to  the  input  (stdin)  of  /V  Since  |  always  and  only  connects  stdout  and  stdin ,  there 
is  no  need  to  explicitly  name  these  channels.  In  Pin,  however,  a  component  can  have  many 
input  and  output  channels,  so  we  need  to  make  them  explicit. 

A  generalization  of  the  pipeline  style  to  multiple  input  and  output  channels  can  be  found  in 
Pin  and  its  predecessors,  WaterBeans  [Plakosh  99]  and  ComTek  [Hissam  02].  The  equivalent 
to  a  pipeline  in  Pin,  at  least  syntactically,  would  be  Pi. stdout /Y stdin.  Note,  however, 
that  Pi. stdout  and  P2. stdin  denote  a  source  and  sink  pin,  respectively,  not  components.  This 
is  not  just  a  lexicographical  distinction,  but  reflects  two  critical  Pin  generalizations  of  the 
pipeline  style: 

•  Components  are  no  longer  primitive;  they  are  a  composite  of  reactions, 
where  we  use  the  CSP  algebraic  operators  ||  and  |||  to  specify  composite 
behavior. 

•  Composition  is  generalized  from  data  flow  to  arbitrary  interaction  schemes, 
such  as,  ( asynchronous,  connection(less),  (uni/multi-)cast,  and 
(2/N-)party  rendezvous. 

As  a  result,  in  place  of  the  simple  algebraic  model  {(7,  we  have  (P,  an  E  E ),  where, 
in  place  of  components,  we  have  reactions  P,  and  in  place  of  the  single  operator  we  have 

an 

a  set  of  operators  one  for  each  interaction  scheme  a  defined  for  an  environment  P,  where 
the  operators  may  have  arbitrary  arity  (i.e.,  interactions  may  involve  an  arbitrary  number  of 
parties). 

So,  for  example,  from  Figure  3,  the  N:1  interaction  ao(co.r  *2*  {ci.s,  C2.s})  denotes  the 
syntactic  composition  of  three  components  co,  Ci,  and  C2,  in  assembly  oq ,  on  pins  co-r,  c\.s 
and  C2.S.  The  interaction  scheme  for  this  composition  is  ^>,  as  defined  in  environment  type 
E0.  We  can  not  tell  whether  ^  is  a  2-ary  (unicast)  or  N-ary  (broadcast)  operator.  This  and 
other  aspects  of  the  semantics  of  this  interaction  must  be  formally  specified. 


3.8  Hierarchical  Assembly 

So  far,  we  have  described  a  component  model  that  is  quite  flat:  components  can  interact  only 
with  components  in  the  same  assembly  and  only  within  a  single  runtime  environment 
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associated  with  that  assembly.  Pin  will  not  scale  to  interesting  problems  without  introducing 
some  form  of  hierarchical  composition.  In  fact,  the  algebraic  model  has  a  hierarchical 
meaning,  as  i?3  =  Ri  R2l  for  some  arbitrary  binary  composition  operator  and  reactions 
^{1,2,3}  ^  induces  a  hierarchy  that  is  rooted  at  #3  and  contains  Ri  and  R2  as  leaves. 

Hierarchical  assembly  in  Pin  always  involves  treating  an  assembly  as  a  component.  That  is, 
the  assembly  has  an  interface  defined  in  terms  of  source  and  sink  pins.  The  correspondence 
between  component  pins  and  assembly  pins  is  established  by  means  of  assembly  junctions. 
Two  forms  of  junctions  are  currently  defined:  null  junctions  and  gateway  junctions.  We  note 
at  the  outset  that  hierarchical  composition  introduces  many  subtle  complexities  not  generally 
addressed  by  component  technology.  Many  of  these  subtleties,  by  intent,  lie  beneath  the 
surface  of  the  following  discussion. 


3.8.1  Null  Junctions 

A  null  junction  has  no  behavior,  hence  the  name.  A  null  junction  is  an  abstraction 
mechanism  that  is  related  to  the  hiding  operator  in  process  algebras  such  as  CSP  and  CCS. 
That  is,  all  the  pins  that  do  not  appear  as  connected  to  null  junctions  are  hidden  from  the 
external  world.  This  is  the  only  form  of  hierarchical  composition  that  is  supported  by 
composition  environments  such  as  FSP  [Magee  01],  Koala  [van  Ommering  02],  and  Tracta 
[Giannakopoulou  99]  (all  of  these  are  based  on  the  original  work  on  Darwin  [Magee  93]).  The 
use  of  null  junctions  is  illustrated  in  Figure  5.  In  this  figure,  we  treat  ao  as  a  subassembly 
with  an  interface  consisting  of  a  single  sink  pin  oq.s  and  a  single  source  pin  aQ.r.  In  this 
example,  ao-r  is  an  alias  for  ao-Co-r,  and  the  real  connector  is  02(00. co-r  ai.co.si).  Using 
null  junctions,  we  can  treat  ao  and  a\  as  components  and  write  the  interaction  as 
a2(ao.r  ^  a\.si). 


Figure  5:  Intra-Assembly  Hierarchy  with  Null  Junctions 
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Hierarchical  assembly  using  null  junctions  is  useful  strictly  for  analysis  purposes  when  there 
is  a  defined  equivalence  relation  that  permits  one  assembly  to  be  replaced  by  another  that  is 
behaviorally  equivalent  with  respect  to  some  property.  For  example,  various  trace-based 
equivalences  are  defined  for  CSP  and  denoted  as  refinement  relations;  in  CCS,  there  are 
various  observational  equivalences,  denoted  as  simulation  relations.  Variations  of  refinement 
and  simulation  preserve  different  kinds  of  properties.  Given  an  equivalence  relation  that 
preserves  the  property  of,  say,  deadlock  freedom,  we  can  be  sure  that  a  demonstrably 
deadlock  free  assembly  can  be  replaced  with  an  assembly  that  is  behaviorally  equivalent  with 
respect  to  deadlock,  but  whose  behavioral  model  is  otherwise  more  abstract. 

Note  that  the  assemblies  in  Figure  5  are  all  of  environment  type  Eq.  The  stipulation  that  null 
junctions  have  no  behavior  means  that  they  do  not  introduce  interactions:  they  introduce 
only  aliases.  This  means  that  the  null  connectors  used  in  O2(ao.r  ai.$i)  can  be  used  only 
to  connect  assemblies  having  the  same  environment  type,  in  the  context  of  an  enclosing 
assembly  of  that  same  environment  type.  This  restriction  is  relaxed  by  gateway  junctions. 

3.8.2  Gateway  Junctions 

Assemblies  in  different  types  of  environments  are  composed  using  gateway  junctions.  Unlike 
null  junctions,  gateway  junctions  do  have  behavior.  Their  purpose  is  to  provide  a  bridge  from 
the  interaction  schemes  (and  connectors)  defined  in  one  environment  type  to  those  defined  in 
some  other  environment  type.  The  main  idea  is  illustrated  in  Figure  6,  which  recasts  the 
previous  illustration  (Figure  5)  so  that  assemblies  ao  and  a\  have  different  environment 
types,  Eq  and  E\:  respectively  and  are  composed  in  an  assembly  having  a  still  different 
environment  type,  E^ .  Strictly  speaking,  it  is  possible  for  Eq  —  E\\  however,  for  gateways  to 
make  sense,  Eq  ^  E2  and  E\  ^  £2. 


Figure  6:  Intra-Assembly/Inter-Assembly  Hierarchy  with  Gateways 
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In  the  example  in  Figure  6,  the  gateway  %.r2  translates  interactions,  as  they  are  defined 
in  environment  type  E0,  to  ^  interactions,  as  they  are  defined  in  environment  type  £3.  The 
interaction  02(00^2  a\-si)  is  enabled  using  an  operator  (connector)  &  defined  in 
environment  type  £2. 

Prom  the  composition  perspective,  the  interactions  between  ao  and  ai  are  semantically 
indistinguishable  from  those  that  would  arise  if  either  or  both  ao  and  a\  were  components 
native  to  E2  and  not  assemblies  that  had  been  transplanted,  via  gateways,  into  £2. 

The  notion  of  composition  across  heterogeneous  environment  types  is  quite  similar  to  what 
Szyperski  described  as  tiered  frameworks  [Szyperski  97].  Terminology  and  other  subtle 
distinctions  aside,  it  is  surprising  that  there  are,  as  far  as  the  authors  know,  no  commercial  or 
research  component  technologies  (other  than  Pin)  that  realize  this  idea. 
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4  Formal  Model  of  CL 


The  formal  model  for  the  behavioral  semantics  of  CL  is  based  on  the  CSP  process  algebra 
[Hoare  85,  Roscoe  98].  CSP  is  used  to  describe  the  behavior  of  components,  as  well  as  the 
interactions  among  them. 

4.1  Conceptual  Model 

One  goal  of  compositional  reasoning  is  to  combine  the  behavior  of  interacting  components  to 
produce  a  single  description  that  explains  the  behavior  of  the  composition.  Figure  7  shows  a 
simple  way  that  composition  could  be  approached  in  CL.  The  behaviors  of  components  c\ 
and  C2  are  specified  as  CSP  processes  PCl  and  PC2,  respectively.  Pins  show  up  in  these 
processes  as  CSP  events,  and  two  processes  interact  whenever  they  synchronize  on  an  event. 
The  simplest  form  of  composition  would  be  to  put  these  processes  in  parallel  over  the  events 
representing  pins,  defining  the  composition  as  PC1  II  Pc2‘ 


Figure  7:  A  Simple  Approach  to  Composition  Semantics 

This  approach  is  too  simple  though.  It  represents  all  interactions  as  synchronizations  of 
source  pin  events  with  sink  pin  events,  that  is,  synchronous  communication.  In  practice, 
components  communicate  using  several  different  types  of  communication,  and  the  differences 
matter. 

Figure  8  illustrates  a  more  flexible  way  to  model  composition.  c\  and  C2  have  CSP  behavior 
specifications  as  above,  but  rather  than  composing  them  directly,  an  additional  CSP  process 
is  interposed  to  represent  the  semantics  of  different  types  of  interactions. 


Figure  8:  Use  of  Glue  to  Model  Interaction  Behavior 


The  CSP  process  representing  interaction  semantics  is  structured  as  the  composition  of  three 
processes:  a  source  glue,  a  sink  glue,  and  a  connection  between  them.  The  source  glue 
describes  the  interaction  semantics  from  the  source’s  perspective  (e.g.,  describing  that  a 
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synchronous  source  expects  an  acknowledgment  as  part  of  each  interaction).  The  sink  glue 
describes  the  interaction  semantics  from  the  sink's  perspective  (e.g.,  describing  that 
asynchronous  interaction  requests  are  queued  until  an  asynchronous  sink  pin  is  ready  for  the 
next  request).  The  connection  binds  a  particular  source  glue  to  a  particular  sink  glue, 
reflecting  the  topology  of  the  interaction. 

This  approach,  while  an  improvement,  is  incomplete  since  we  have  not  yet  addressed 
implementation  concurrency.  Is  concurrent  activity  possible  within  a  component?  Can 
multiple  components  concurrently  interact  with  the  same  sink  pin  of  another  component? 

We  could  try  to  avoid  these  issues  by  dictating  that  all  sink  pins  of  a  component  be  threaded 
and  share  the  same  thread  of  execution.  But  this  restriction  is  not  very  satisfactory:  it  means 
that  we  cannot  model  reentrant  sink  pins,  which  explicitly  permit  multiple  concurrent 
interactions.  It  also  means  a  loss  of  useful  analysis  results.  Errors  in  concurrent  systems  are 
often  the  result  of  race  conditions  among  concurrent  tasks,  conditions  that  are  notoriously 
difficult  to  detect  in  testing.  Model  checking,  on  the  other  hand,  is  well  suited  to  detect  such 
errors;  but,  we  cannot  detect  them  if  we  do  not  model  the  inherent  concurrency  in  the  first 
place. 

Therefore,  we  address  implementation  concurrency  explicitly  in  our  semantic  model.  We  use 
two  concepts-reactions  and  logical  threads-to  structure  a  component’s  behavior  specification 
in  a  way  that  models  the  concurrent  threads  of  execution  found  in  its  implementation. 

Each  reaction  has  a  specific  interpretation  in  terms  of  the  threadedness  of  its  component.  All 
sink  pins  handled  by  the  same  thread  are  collected  into  a  single  reaction  that  defines  the 
behavior  of  that  thread.  Each  sink  pin  that  is  not  threaded  is  specified  by  its  own  reaction, 
which  defines  the  behavior  that  is  executed  in  the  caller’s  thread.  These  interpretations  lead 
to  the  following  constraints  on  reactions: 

•  Every  sink  pin  must  appear  in  exactly  one  reaction. 

•  A  source  pin  may  appear  in  more  than  one  reaction,  but  every  source  pin 
must  appear  in  at  least  one  reaction. 

•  All  sink  pins  appearing  in  the  same  reaction  must  be  handled  by  the  same 
thread. 

•  All  sink  pins  handled  by  the  same  thread  must  appear  in  the  same  reaction. 

However,  the  interpretation  of  reactions  does  not  fully  address  reentrant  sink  pins.  Can 
multiple  interactions  occur  concurrently  on  a  reentrant  sink  pin?  The  answer  is,  of  course, 
yes,  but  modeling  the  reaction  for  a  reentrant  sink  pin  as  a  single  CSP  process  does  not 
accurately  model  this  concurrency. 

The  simplest  solution  is  to  copy  the  reaction  N  times  to  permit  up  to  N  concurrent 
interactions  involving  a  reentrant  sink  pin.  We  call  each  such  copy  of  a  reaction  a  logical 
thread.  For  reentrant  sink  pins,  many  logical  threads  may  correspond  to  the  same  reaction. 
For  all  other  reactions,  exactly  one  logical  thread  corresponds  to  each  reaction. 

A  logical  thread  is  a  CSP  process  modeling  a  thread  of  execution  that  is  implemented  by  the 
component,  regardless  of  whether  that  thread  of  execution  occurs  on  a  thread  managed  by 
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that  component.  When  describing  interactions  among  components,  we  use  a  definition  of  a 
component’s  behavior  that  is  structured  in  terms  of  logical  threads,  rather  than  reactions. 
This  is  a  simple  transformation  of  the  user’s  specification,  which  is  structured  in  terms  of 
reactions  and  models  the  true  concurrency  of  the  component. 

Alternatively,  we  could  require  that  component  specifications  already  have  the  correct 
number  of  copies  of  reentrant  sink  pin  reactions.  But,  what  is  the  correct  number  of  copies  to 
make?  Unfortunately,  the  answer  is:  it  depends.  The  number  of  copies  should  be  the  same  as 
the  number  of  logical  threads  of  other  components  that  can  interact  with  the  reentrant  sink 
pin,  and  that  number  depends  on  what  is  in  the  component’s  environment.  Without  knowing 
a  component’s  environment,  a  component  specifier  cannot  determine  the  number  of  copies  to 
make,  and  if  the  component  is  to  be  used  in  several  contexts,  the  number  will  vary  with 
context.  As  such,  relating  reactions  to  logical  threads  is  a  task  best  performed  when  an 
environment  has  been  specified  (i.e.,  when  we  know  what  other  components  interact  with  the 
component),  rather  than  when  a  component  is  specified. 

Returning  to  the  example  illustrated  in  Figure  4,  R%  is  a  reaction  for  a  reentrant  sink  pin  S4. 
When  the  component  interacts  with  only  one  other  component,  and  that  component  has  two 
logical  threads  that  interact  with  54,  there  are  two  logical  threads  for  pin  54,  each  of  which  is 
a  copy  of  R3. 


4.2  Formal  Definitions 

4.2.1  Definition  of  Sink  Pin 

A  sink  pin  is  represented  a s  a  CSP  event  of  the  same  name.  Use  of  a  sink  pin  is  represented 
by  a  pair  of  these  events,  one  denoting  the  initiation  of  an  interaction  on  that  pin  (e.g.,  a 
function  being  called)  and  the  other  denoting  the  completion  of  an  interaction  on  that  pin 
(e.g.,  a  function  returning).  Any  other  interactions  or  activities  that  are  internal  to  a 
component  and  that  are  performed  before  completing  the  interaction  will  appear  as  events 
between  those  two  events.  Non-sink  events  may  appear  after  the  second  occurrence  of  the 
sink  event  only  if  the  sink  pin  has  a  thread. 

A  reaction  describing  the  behavior  of  an  interaction  on  reentrant  sink  pin  s  that  engages  in 
an  interaction  on  source  r  before  completing  the  interaction  on  sink  s  would  be  written  as: 
P  =  4r- >  s  — >  P.  It  would  be  illegal  to  put  any  event  after  the  second  s,  since  a 

reentrant  sink  pin  never  has  a  thread. 

A  sink  pin  may  represent  an  interaction  involving  in/out  data  parameters.  This  is 
represented  using  CSP  compound  events,  where  the  sink  pin  name  is  the  name  of  the 
channel,  and  data  parameters  are  data  components  appended  to  the  channel  using  normal 
CSP  conventions  (i.e.,  e\x  represents  event  e  that  supplies  data  value  x,  and  ely  represents 
event  e  that  accepts  a  data  value  y). 

The  first  occurrence  of  a  sink  event  in  a  reaction  may  include  input  data  parameters  (e.g., 
s?x?y),  but  may  not  include  output  data  parameters.  The  second  occurrence  of  a 
synchronous  sink  event  in  a  reaction  may  include  output  data  parameters  (e.g,  s!x!i/),  but 
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may  not  include  input  data  parameters.  The  second  occurrence  of  an  asynchronous  sink 
event  may  not  include  any  data  parameters. 


4.2.2  Definition  of  Source  Pin 

A  source  pin  is  also  represented  as  a  CSP  event  of  the  same  name.  Use  of  a  source  pin  is 
represented  by  a  pair  of  these  events,  one  denoting  the  initiation  of  an  interaction  on  that  pin 
(e.g.,  calling  a  function)  and  the  other  denoting  the  completion  of  an  interaction  on  that  pin 
(e.g.,  the  return  of  the  function).  No  other  events  may  appear  between  these  two  events. 

A  reaction  describing  the  behavior  of  an  interaction  on  sink  pin  s  that  engages  in  an 
interaction  on  source  r  before  completing  the  interaction  on  sink  s  would  be  written  as: 

P  =  5-»r— >>r— >  $  -*  P.  It  would  be  illegal  to  put  any  event  between  the  two  occurrences 
of  r  in  the  reaction. 

As  with  sink  pins,  source  pins  may  represent  an  interaction  involving  in/out  data  parameters, 
and  the  same  CSP  representation  is  used.  The  first  occurrence  of  a  source  event  in  a  reaction 
may  include  output  data  parameters  (e.g.,  r\x\y),  but  may  not  include  input  data 
parameters.  The  second  occurrence  of  a  synchronous  source  event  in  a  reaction  may  include 
input  data  parameters  (e.g.,  rlxly),  but  may  not  include  any  output  data  parameters.  The 
second  occurrence  of  an  asynchronous  source  event  may  not  include  data  parameters. 


4.2.3  Definition  of  Reaction 

A  reaction  is  represented  as  a  CSP  process.  The  initial  set  of  events  accepted  by  that  process 
should  be  the  sink  pins  described  by  the  reaction.  Reactions  are  transformed  into  logical 
threads  when  a  component  is  composed  with  other  components  (i.e.,  when  the  environment 
of  the  component  is  known). 

4.2.4  Definition  of  Logical  Thread 

A  logical  thread,  which  is  represented  as  a  CSP  process,  is  a  copy  of  a  reaction  that  executes 
in  a  particular  context.  A  reaction  for  a  component’s  thread  will  equal  a  logical  thread.  A 
reaction  for  a  reentrant  sink  pin  may  be  transformed  into  multiple  logical  threads,  one  per 
context  that  can  interact  with  the  pin. 

4.2.5  Definition  of  Component 

A  component  is  represented  by  the  3-tuple  (5,  1Z,  V)  defined  below. 

•  S  is  the  set  of  the  component’s  sinks. 

•  1Z  is  the  set  of  the  component’s  sources. 

•  V  is  the  component’s  behavior,  specified  as  a  CSP  process.  V  is  structured 
as  the  composition  (using  ||  or  |||)  of  the  component’s  reactions  together 
with  any  auxiliary  CSP  processes  needed  to  coordinate  the  reactions  (e.g., 
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to  model  a  lock  used  by  multiple  reactions).  An  auxiliary  CSP  process  is 
defined  to  be  any  process  that  does  not  refer  to  any  of  the  component’s 
pins. 

4.2.6  Definition  of  Assembly 

An  assembly  is  represented  by  the  4-tuple  (*4C,  top ,  T,  threadmap)  defined  below. 

•  AC  is  the  finite  set  of  components  in  the  assembly.  No  two  components 
within  an  assembly  can  have  the  same  name. 

•  top  is  the  finite  set  of  { source  pin ,  sink  pin)  pairs  defining  the  assembly’s 
topology.  Each  pair  represents  a  source  pin  that  interacts  with  a  sink  pin. 
The  value  of  top  is  supplied  by  the  component  assembler,  but  must 
conform  to  the  following  constraints: 

V(c,-.r,  Cj.s)  G  top  •  Ci  ±  c j  A  r  G  Ci.lZ  A  s  G  Cj.S 

That  is,  every  connection  must  be  between  a  source  pin  and  a  sink  pin  of 
two  different  components. 

Vci.r,Cj.Si  •  ((c,.r,  Cj.Sj)  G  top  A  Synchronous (ci.r)) 

(->3 ck,Sj  •  ( Ci.r,ck.Sj )  €  top  A  ck.Sj  ±  Cj.Si)) 

That  is,  if  a  source  pin  is  synchronous,  it  cannot  be  connected  to  more 
than  one  sink  pin. 

•  T  is  the  finite  set  of  (pin,  logical  thread)  pairs  defining  the  concurrency  of 
pins  in  the  assembly.  Each  pair  represents  a  logical  thread  of  the  pin’s 
component  that  can  interact  via  the  pin.  The  value  of  T  is  calculated 
based  on  components’  reactions  and  an  understanding  of  the  threadedness 
of  the  components’  environments,  and  satisfies  the  following  constraints: 

V(c.p,  c.t)  G  T  •  p  G  ( c.S  U  c.lZ)  A  t  is  a  logical  thread  of  c 

That  is,  each  logical  thread  of  a  component  interacts  only  via  pins  of  that 
component. 

V  c.p  •  (p  G  c.S  A  p  is  not  reentrant)  =>  (#{£  |  (c.p,  c.t)  G  T}  =  1) 

That  is,  all  sink  pins  that  are  not  reentrant  have  exactly  one  logical  thread. 

•  threadmap  is  a  finite  set  of  ( logical  thread ,  logical  thread)  pairs.  Each  pair 
represents  a  logical  thread  of  one  component  that  interacts  (via  source  and 
sink  pins)  with  a  logical  thread  of  another  component.  Like  T,  the  value  of 
threadmap  is  calculated  based  on  components’  reactions  and  an 
understanding  of  the  threadedness  of  the  components’  environments.  The 
calculated  value  of  threadmap  must  satisfy  the  following  constraints: 

V(ci.ti,  Cj.tj)  G  threadmap  •  3r,s  •  (cj.r,Cj.s)  G  top  A  (cj.r,  c2*.^)  G  T  A 

{cj.s.Cj.tj)  G  T 

That  is,  every  mapping  between  logical  threads  must  be  between  logical 
threads  of  two  different  components  and  must  correspond  to  the  logical 
threads  of  a  pair  of  pins  connected  in  top. 
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V  Ci.r.  Cj.s ,  Cj.^  •  (r  £  cz.7£  A  (c,.r.  cz.£z)  £  T  A  (cz.r,  Cj.s)  £  £op)  => 

(3  Cj.tj  •  (ci.tii  Cj.tj)  G  threadmap  A  (cj.s,  Cj.tj)  £  T) 

That  is,  every  logical  thread  for  a  source  pin  that  interacts  with  some  sink 
pin  must  be  mapped  to  at  least  one  logical  thread  of  that  sink  pin. 

V  Ci.r,  Cj.s,  Cj.tj  •  (s  e  Cj.s  A  (cj.s,  cj.tj)  €  T  A  (cj.r,  cj.s)  €  top)  => 

(Bci.ti  •  (cj.ti,  Cj.tj)  G  threadmap  A  (cz.r,  cz.£z)  G  T) 

That  is,  every  logical  thread  for  a  sink  pin  that  interacts  with  some  source 
pin  must  be  mapped  to  at  least  one  logical  thread  of  that  source  pin. 

V  Cj.r,  Cj.s ,  Cj.tj  •  (s  £  Cj.S  A  ( Cj.s ,  Cj.tj )  £  T  A  Cj.s  is  a  reentrant  sink  pin  A 

(cj.r,Cj.s)  G  £op)  =>  ( Bci.ti  •  (czJz,  CjJj)  G  threadmap  A  (c,*.r,  cz.£z)  G  T  A 
V  c*.t*  •  Cj.tj)  G  threadmap  =>  (c*.4  =  c,-.*,-)) 

That  is,  every  logical  thread  for  a  reentrant  sink  pin  that  interacts  with 
some  source  pin  must  be  mapped  to  exactly  one  logical  thread. 


4.2.7  Definition  of  interaction 

An  interaction  is  defined  in  the  context  of  a  particular  assembly  and  is  represented  by  a 
( source  pin ,  sink  pin)  pair  that  is  an  element  of  top.  Source  r  of  component  c*  is  the  source 
pin  participating  in  the  interaction.  Sink  s  of  component  Cj  is  the  sink  pin  participating  in 
the  interaction. 


4.3  Composition  Semantics 

When  composing  two  components,  c\  and  C2,  we  define  the  semantics  using  the  CSP  parallel 
composition  of  their  behavior  specifications,  PC1  and  PC2.  However,  as  mentioned  earlier,  it's 
not  as  simple  as  defining  the  composition  to  be  PCl  ||  PC2.  There  are  other  important  issues 
to  consider. 

First,  we  need  to  transform  Pc,  and  PC2  from  compositions  of  reactions  to  compositions  of 
logical  threads.  Then,  we  need  to  carefully  plan  the  synchronization  between  CSP  processes 
such  that  synchronization  occurs  only  on  certain  events.  To  accomplish  this,  we  apply  an 
event-renaming  convention  that  gives  different  names  to  events  that  should  not  be 
synchronized.  Finally,  we  need  to  interpose  CSP  processes  that  model  the  behavior  of  the 
different  types  of  interactions  that  can  occur  between  components. 

The  following  subsections  address  these  topics.  We  start  by  addressing  the  necessary 
transformations  to  component  behavior  descriptions  (i.e.,  reaction  to  logical  thread 
transformation  and  event  renaming).  This  is  followed  by  formally  defining  the  different  types 
of  interactions  between  a  source  pin  and  a  sink  pin.  Finally,  we  present  the  general  model  for 
defining  the  behavior  of  an  assembly  of  components  with  an  arbitrary  finite  set  of 
interactions. 
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4.3.1  Composition  Semantics:  Components 

As  mentioned  earlier,  a  component  is  described  by  a  CSP  behavior  specification  Pc,  which  is 
structured  in  terms  of  CSP  processes  modeling  its  reactions.  This  behavior  specification 
needs  to  be  transformed  in  two  ways  to  exhibit  the  correct  semantics  when  combined  in  an 
interaction  or  assembly. 

First,  we  need  to  transform  reactions  into  logical  threads.  For  reactions  that  do  not  model 
reentrant  sink  pins,  the  logical  thread  is  equal  to  the  reaction.  For  reactions  that  model  a 
reentrant  sink  pin,  we  need  to  replace  the  reaction  with  N  copies  of  the  reaction,  each  of 
which  is  a  distinct  logical  thread  and  models  the  possibility  of  a  different  concurrent 
interaction  with  the  sink  pin.  For  the  reaction  for  reentrant  sink  pin  c.s, 

N  =  #{t\(c.s,c.t)eT}.' 

For  example,  consider  the  composition  illustrated  in  Figure  9.  The  reaction  of  reentrant  sink 
pin  s  of  component  c\  is  given  by  Rs  =  s  x  x  ->  s  Rs.  The  behavior  specification  of 
the  sink  pin’s  component  is  defined  as  PCl  =  Rs  |||  Rt,  where  Rt  is  another  reaction  of  the 
component  that  handles  non-reentrant  sink  pin  t.  In  this  assembly,  c\  is  composed  with  C2- 
C2  has  two  logical  threads  that  use  a  source  pin  connected  to  ci’s  reentrant  sink  pin; 
consequently,  we  need  two  copies  of  the  reaction  that  handles  activity  on  reentrant  sink  pin  s 
(i.e.,  two  logical  threads).  The  transformed  behavior  of  ci  could  be  rewritten  as 
P'Ci  =  (|||t€{tl  t  :  Rs)  HI  Rt-  This  process  has  two  copies  of  Rs.  each  with  a  different  prefix 
corresponding  to  a  different  logical  thread.3 


Figure  9:  Composition  of  Two  Components 


Second,  we  need  to  apply  an  event-renaming  convention  to  Pet  to  ensure  proper 
synchronization.  We  use  a  convention  that  gives  each  pin  used  by  each  component’s  logical 
thread  a  unique  name.  For  example,  a  source  pin  that  is  used  by  two  different  logical  threads 
is  renamed  by  prefixing  the  name  of  the  source  pin  with  the  name  of  the  component  and 
logical  thread  in  which  it  used.  Thus,  each  logical  thread  has  its  own  copy  of  the  event  (e.g., 
ci.ti.s  and  ci.fe-s)- 

Event  renaming  is  important  when  c  is  composed  with  another  component.  Interactions  on  a 


3  This  is  a  simplification.  By  relabeling  all  events  in  Rs  with  a  prefix  unique  to  the  logical  thread,  problems 
could  be  introduced  if  R3  contains  any  events  that  are  internal  to  the  component.  For  example,  if  several 
logical  threads  use  an  internal  event  to  coordinate  access  to  a  shared  resource  within  the  component,  rela¬ 
beling  this  event  differently  in  each  logical  thread  would  incorrectly  eliminate  synchronization  among  the 
logical  threads. 
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source  pin  that  occur  in  one  logical  thread  must  be  distinguished  from  interactions  on  the 
same  source  pin  occurring  in  other  logical  threads.  In  particular,  if  the  source  pin  uses  input 
and  output  data  parameters,  we  must  distinguish  between  two  interactions  to  correctly 
associate  related  input  and  output  data  parameters. 

For  a  given  logical  thread,  c.£,  which  is  a  transformation  of  reaction  7Z,  the  behavior  of 
logical  thread  c.t  is  defined  by  the  process  LT*,  where 

LTt  =  R  [Vp  E  (c.S  U  c.TZ)  •  c.t.p\p,V  e  E  ( aR  \  ( c.S  U  c.TZ))  •  c.p\p] 

Formally,  we  define  the  fully  transformed  behavior  specification  of  component  c  as  Pfc ,  where 
P'c  is  produced  by  making  substitutions  in  Pc.  As  mentioned  earlier,  Pc  is  required  to  be 
structured  as  a  composition  of  CSP  processes,  including  both  reactions  and  auxiliary  CSP 
processes.  In  deriving  P',  we  retain  the  original  composition  semantics  (the  choice  of 
combining  CSP  processes  using  ||  or  |||)  among  the  CSP  processes,  but  we  transform  each 
reaction  into  its  corresponding  logical  thread(s).  To  do  this,  we  iterate  through  each  CSP 
process  P  in  the  composed  process  Pc  and  make  the  following  substitution: 

•  If  the  process  represents  a  reaction,  iZ,  that  does  not  describe  the  behavior 
of  a  reentrant  sink  pin,  substitute  LTt  for  R. 

•  If  the  process  represents  a  reaction,  R ,  that  describes  the  behavior  of 
reentrant  sink  pin  c.s,  substitute  |||^c  s  c  LTt  for  R . 

•  If  the  process  represents  an  auxiliary  process,  substitute  P  for  P  (i.e., 
make  no  change). 

4.3.2  Composition  Semantics:  Interactions 

Interaction  c,.r  Cj.s  is  a  connection  between  source  r  of  component  C{  and  sink  s  of 
component  Cj.  Formally,  we  represent  such  an  interaction  as 

I{ci.r ,  Cj.s)  =  P'{ci)  ||  Glue{ci.r ,  cj.s)  ||  P’{cj) 

where  Glue(ci.r ,  Cj.s)  is  a  process  that  describes  the  semantics  of  the  interaction  shared 
between  c,.r  and  c;.s,  and  is  defined  as 

Glue(ci.rxj.s)  =  SoG(ci.r)  || 

(1 1 1  |  ( c,  .r,c,.t,)€TA(cj  .5,  c;.tj)GTA(c,  .f,  )€threadmap  CoTlTl(Ci  .V ,  Cj.Zj,  Cj.S<  Cj.tj)) 

||  SiG(cj.s) 

where  SoG(c{.r ),  the  source  glue  for  source  r  of  component  c*,  is  the  process  that  defines  the 
interaction  semantics  from  the  source’s  perspective  (e.g.,  describing  that  a  synchronous  source 
expects  an  acknowledgment  as  part  of  each  interaction).  It  takes  into  account  that  there 
might  be  multiple  logical  threads  in  c,*  on  which  interactions  on  r  might  occur  concurrently. 

SiG(cj.s ),  the  sink  glue  for  sink  s  of  component  c;-,  is  the  process  that  defines  the  interaction 
semantics  from  the  sink’s  perspective  (e.g.,  describing  that  asynchronous  interaction  requests 
are  queued  until  an  asynchronous  sink  pin  is  ready  for  the  next  request).  It  takes  into 
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account  that  there  might  be  multiple  logical  threads  in  Cj  on  which  interactions  on  s  might 
occur  concurrently. 

Conn(ci.r,  Cj.ti,  Cj.s ,  Cj.tj)  is  the  process  that  binds  one  logical  thread  Cj.tj  of  a  source  r  of 
component  c:-  to  one  logical  thread  Cj.tj  of  a  sink  s  of  component  Cj.  This  binding  is 
accomplished  by  matching  left  events  shared  with  a  particular  source  glue  to  right  events 
shared  with  a  particular  sink  glue. 

The  semantics  of  an  interaction  vary  with  the  type  of  interaction,  so  SoG(cj.r),  SiG(cj.s), 
and  Conn(ci.r ,  C\ . ti ,  Cj.s,  Cj.tj)  are  defined  differently  depending  on  whether  each  interaction 
is  reentrant,  mutex,  or  asynchronous. 


Reentrant  Interactions 

The  process  definitions  for  reentrant  interactions  are  as  follows: 

SoG(ci.r)  =  |||{ll(Cl.r,Cl.t;)er  SoG{*.r ,  a.t i) 

SoG(ci.r ,  Ci.t{)  =  Ci.ti.r  — »  Ci.ti.r.left  — >  Ci.ti.r.left  — >  — »  5oG(c,-.r, 

(7orm(c,-.r,  Cj.5,  CjJj)  =  Ci.ti.r.left  — >  Cj.tj. s.right  — >  Cj.tj. s. right  Ci.ti.r.left  -* 

(7on7l(c,*.r,  Cj.£j,  Cj.S,  Cj.fj) 

5zG(cj.s)  =  IIItj-Kcj.sjCj.tjjeT 

£?G(cj.s,  c j . tj )  =  Cj.tj. s.right  — »  Cj.tj. s  ->  Cj.tj. s  — )■  Cj.tj. s.right  — >  SiG(cj.s,  Cj.tj) 

For  reentrant  interactions,  the  mapping  between  logical  threads  of  a  source  pin  and  logical 
threads  of  a  sink  pin  is  one  to  one.  As  such,  we  could  uniquely  identify  right  events  to  the 
sink  glue  either  by  prefixing  them  with  source  pin  information  (component,  logical  thread, 
and  pin  names)  or  by  prefixing  them  with  sink  pin  information.  We  opt  for  sink  pin 
information  as  it  allows  a  simpler  SiG(cj.s)  process  definition. 


Mutex  Interactions 


The  process  definition  of  SoG(cj.r)  for  mutex  interactions  is  the  same  as  for  the  reentrant 
case.  The  remaining  process  definitions  for  mutex  interactions  are  as  follows: 


Conn(ci.r,  Ci.ti,  Cj.s,  Cj.tj)  —  Ci.ti.r.left  — >  Ci.ti.r. right  Ci.ti.r. right  ->  Ci.ti.r.left 

Conn(ci.r ,  Cj.ti,  Cj.s ,  Cj.tj) 

SiG(cj.s)  =  SiG(cj.s ,  Cj.tj),  where  tj  =  the  only  element  of  {£  |  ( Cj.s ,  Cj.t)  G  T} 
SiG(cj.s,  Cj.tj)  =  WaitRight{cj.s,  Cj.tj) 

WaitRight(cj.s,  Cj.tj )<>  =  nc..r|(c..rjC..s)etop  c^Ub  Wight  cj.tj.s  -> 

WaitRight(cj.s,  Cj.tj)<Ci.ti.r> 

WaitRight{Cj.s,  cj.tj) Q^<x  y  z>  =  (□Ci.r|(cj.riC..s)etopci?<i!r!n5W  -> 

Cj.tj)  ^  ^  ) 

<ct.tt.r>  Q  <x.y.z> 

□  Cj.tj. s  ->  x.y.z.right  — »  Next(cj.s,  Cj.tj)Q 
Next(cj.s,  Cj.tj) =  VFarti2i^W(cj.s,  Cj.ij)<> 

=  Cj.tj. s  — ►  W^ai£Rt0Af(cj.s,  Cj.tj) 


Nexticj.s ,  Cj.tj)  ^ 

3  3  3  7  Q  <x.y.z> 


<x.y.z> 


For  mutex  interactions,  the  mapping  between  logical  threads  of  a  source  pin  and  logical 
threads  of  a  sink  pin  is  many  to  one  since  there  is  always  exactly  one  sink  logical  thread.  As 
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such,  to  uniquely  identify  right  events  to  the  sink  glue,  we  must  prefix  them  with  source  pin 
information. 

Note  that  we  have  modeled  the  queue  of  waiting  interactors  as  a  FIFO  queue.  Other  queuing 
policies  are  possible  and  could  be  introduced  as  variants  of  SiG(cj.s). 

Asynchronous  Interactions 

The  process  definitions  for  asynchronous  interactions  are  a  little  more  complicated,  because  it 
is  possible  to  connect  an  asynchronous  source  pin  to  multiple  asynchronous  sink  pins. 
Whenever  a  source  is  connected  to  multiple  sinks,  the  semantics  call  for  the  source  to  interact 
with  all  the  connected  sinks,  not  just  a  subset  of  them.  Further,  the  interaction  represents  a 
sequence  of  two-way  interactions,  not  a  single  N-way  interaction. 

Below,  we  define  two  alternative  meanings  for  such  an  interaction.  The  first  meaning,  which 
we  call  non-deterministic,  leaves  the  order  of  two-way  interactions  unspecified.  The  order  can 
be  different  each  time  the  source  pin  is  activated.  The  second  meaning,  which  we  call 
deterministic,  allows  the  order  to  be  explicitly  specified  and  so  is  the  same  each  time  the 
source  pin  is  activated. 

Non-Deterministic  Semantics.  The  non-deterministic  semantics  are  presented  below: 
SoG(a.r)  =  |llt,|(c,.r,c,.t1)eT  SoG(ci.r,  Cj.i,-) 

SoG(ci.r,  Ci.ti)  —  C{.ti.r  — »  SendAll(ci.r,  Ci.ti)conns  ;  SoG(ci.r,  Ci-U) 

SendAll(ci.r,  Ci.ti)$  =  Skip 

SendAll(ci.r ,  a .ti)s  =  )eS  Ci.ti.r. Cj.tj.s. left  ->  SendAll{ci.r,  c,.^)5\{(Cj>SjCjtg} 

conns  =  {(cj.s,  Cj.tj)  |  (c,.r,Cj.s)  E  top  A  ( Ci.r,Ci.ti,Cj.s,  Cj.tj )  E  threadmap  A 
{Cj.s,  Cj.tj)  E  T } 

Conn(ci.r,  C{.ti,  Cj'S,  Cj.tj)  =  a.ti.r.  Cj.tj.s. left  — >  Cj.tj.s. right  —>  Conn(ci.r,  Ci.ti,  Cj.s.  Cj.tj) 

SiG(cj.s)  =  SiG(cj.s ,  Cj.tj).  where  tj  =  the  only  element  of  {£  |  (cj.s^Cj.t)  E  T} 

SiG(cj.s,  Cj.tj)  =  Wait  Right  {cj.s,  Cj.£j)<> 

WaitRight(cj.s^  Cj.tj)  <:>  =  Cj.tj  .s.  right  — >  Cj.tj.s  — >  W ait  Right  {cys,  Cj.tj)  <s> 

WaitRight(cj.$,  Cj.tj)  ^  =  Cj.tj.s. right  Wait  Right  (cj.s.  Cj.tj)  ^  ^ 

Q  <x>  <s>  Q  <x> 

□  Cj.tj.s  — >  N ext [cj.s.  Cj.tj) q 

N ext (c j. s.  Cj.tj) <>  =  WaitRight(cj.s,  Cj.tj)<:> 

Next  (cj.s.  Cj.tj)  ^  =  Cj.tj.s  — ►  Wait  Right  (cj.s.  Cj.tj)  ^ 

Q  <x>  Q  <x> 

Deterministic  Semantics.  The  component  assembler  must  specify  additional  information 
for  this  alternative.  Specifically,  the  order  in  which  the  source  will  interact  with  each 
connected  sink  must  be  specified.  The  following  CSP  processes  assume  that  this  information 
is  specified  as  a  sequence  of  pairs  ( Cj.s ,  Cj.tj)  called  conns.  The  definitions  of 
Conn(ci.r)  Cj.ti.  Cj.s ,  Cj.tj)  and  SiG(cj.s)  are  the  same  as  for  the  non-deterministic 
alternative. 

SoG{d.r)  =  Mlil|(ct.r,Ct.*l)er  SoGfa.r,  a-U) 
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SoG(ci.r,  Q.ti)  =  Ci.ti.r  SendAll(ci.r,  Ci.ti) conns  ;  Ci.ti.r  SoG(ci.r,  Ci.ti) 

SendAll(ci.r ,  Cj . ^i)<>  =  Skip 

SendAll(ci.r ,  Cj  J2)  ^  =  Ci.ti.r.Cj.tj.s.left  ->  SendAll{c{.r<  Cj.^)g 

In  the  context  of  an  interaction  between  two  asynchronous  pins,  the  mapping  between  logical 
threads  of  a  source  pin  and  logical  threads  of  a  sink  pin  is  many  to  one,  since  there  is  exactly 
one  sink  logical  thread.  However,  in  the  context  of  an  assembly,  the  mapping  is  many  to 
many  since  a  source  pin  can  be  connected  to  multiple  sink  pins.  This  means  that  to  uniquely 
identify  right  events  to  the  sink  glue  we  must  prefix  them  with  source  and  sink  information. 

Again,  we  have  modeled  the  queue  of  waiting  interactors  as  a  FIFO  queue.  Other  queuing 
policies  are  possible  and  could  be  introduced  as  variants  of  SiG(cj.s).  Careful  inspection  will 
reveal  that  the  information  being  queued  is  not  used  beyond  keeping  tracking  of  how  many 
requests  are  pending.  This  would  not  be  the  case  if  the  interaction  included  input  data 
parameters,  however,  as  the  parameters  are  queued  as  part  of  the  s  events.  This  enables  the 
sink  pin  to  handle  different  requests  (i.e.,  those  with  different  input  parameters)  in  the 
correct  order. 

4.3.3  Composition  Semantics:  Assemblies 

The  composed  behavior  of  an  assembly  of  a  finite  set  of  components  AC  with  connections  as 
defined  in  top ,  logical  thread  allocation  to  pins  as  defined  in  T,  and  logical  thread 
connections  as  defined  in  threadmap  is  given  by 

Assembly  =  Components  [AC)  ||  Source  Glues(AC)  ||  SinkGlues(AC)  ||  Connections  {AC ) 
Components(AC)  =|||cej4C  P*c 
SourceGlues(AC)  =  Illc. resources  SoG{c.r) 

AllSources  =  {c.r  \  c  e  AC  A  r  e  c.TZ} 

SinkGlues(AC)  =  |||c.,6ilHSSflb  SiG{c.s) 

AllSinks  =  {c.s  |  c  G  AC  A  s  G  c.S} 

Connections  {AC)  =  lll(Ci.r,Ci.s)etoP  Conns  (c.-r,  Cj.s) 

Conns(ci.r,Cj.s)  = 

lllti,tj  \(ci.U,Cj.tJ)ethreadmapA(cl.r,Ci.ti)£TA(cj.s,Cj.tj)€T  Conn(ct*.r,  Cj.S,  Cj  .tj) 

The  correct  versions  of  iSoG(c2.r),  Conn{c{.r,  Cj.i2,  Cj.s,  cj.tj ),  and  SiG(cj.s)  must  be  used  for 
each  interaction  between  a  pair  of  pins. 
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5  Compositional  Minimization 


The  previous  section  presented  simple  definitions  of  composition.  The  general  form  has  been 
to  combine  the  behavior  specifications  for  the  interacting  components  with  the  behavior 
specifications  for  the  glue  representing  different  types  of  interaction.  This  general  form 
results  in  models  that  are  typically  larger  than  necessary.  For  example,  often,  some  of  a 
component’s  behavior  is  irrelevant  to  a  composition,  because  not  all  sink  pins  are  stimulated. 
This  section  presents  a  series  of  modified  composition  definitions.  Each  one  attempts  to 
eliminate  unnecessary  CSP  process  descriptions. 

One  common  pattern  in  eliminating  CSP  process  descriptions  is  to  restrict  the  process 
description  of  a  component  to  include  only  some  of  the  logical  thread  processes  of  which  the 
component  is  composed.  The  restriction  of  component  process  description  Pc  to  a  set  of 
logical  threads  T,  PC\T ,  is  defined  by  transforming  Pc  as  follows: 

Iterate  through  each  CSP  process  of  which  Pc  is  composed;  for  each  process  P 

•  If  P  represents  a  logical  thread  t  and  f  G  T,  leave  P  unchanged. 

•  If  P  represents  a  logical  thread  t  and  t  £  T,  replace  P  with  NOTHING. 

•  If  P  represents  an  auxiliary  process  and  3  t  E  T  •  aP  fl  at  /  0,  leave  P 
unchanged. 

•  If  P  represents  an  auxiliary  process  and  V  t  E  T  •  aP  fl  =  0,  replace 
P  with  NOTHING . 

All  processes  remain  connected  by  their  original  composition  operators  (i.e.,  ||  or  |||). 

Next,  iterate  through  the  composition  and  collapse  the  expression  by  applying  the  following 
two  rules: 

•  P  ||  NOTHING  =  P 

•  P  HI  NOTHING  =  P 
The  result  is  the  value  of  Pc  |~  T. 

The  above  technique  is  algorithmic  for  reasons  of  simplicity.  We  considered  options  that 
would  replace  processes  with  Stop  or  Run ,  but  none  could  be  applied  as  uniformly  as  the 
algorithmic  solution.  While  P  ||  RunQp  —  P,  P  |||  Runap  =  Runap.  Likewise,  while 
P  HI  StopaP  =  P,  P  ||  StopaP  =  Stopap.  Consequently,  tool  support  would  be  used  to 
produce  definitions  for  processes  of  the  form  Pc  f  T,  much  as  tool  support  would  be  used  to 
produce  definitions  for  P' . 

5.1  Compositional  Minimization:  Interactions 

A  more  compact  representation  can  be  produced  using  the  following  redefinition  of 

I(c{.r ,  Cj.s): 

I{a.r,Cj.s )  =  (P't  r  rCl.r)  II  MinGlue{ci.r,Cj.s)  ||  (P'.  |"  TCj,s) 
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TC).r  is  the  set  of  logical  threads  of  c,  that  can  participate  in  interactions  via  source  pin  r. 
TC]'S  is  the  set  of  logical  threads  of  Cj  that  can  participate  in  interactions  via  sink  pin  s.  TC).r 
and  TCj'S  are  calculated  as  the  union  of  those  logical  threads  directly  involved  (T{nv)  in 
interactions  on  a  pin  and  those  logical  threads  interacting  (Tint)  with  the  logical  threads 
directly  involved.  Interacting  logical  threads  are  those  that  can  influence  the  behavior  of  the 
involved  logical  threads  directly  or  indirectly,  interacts  is  a  relation  specifying  those  logical 
threads  that  interact  with  each  other  by  synchronizing  on  one  or  more  internal,  non-pin 
events.  TCi.r  and  TCj,s  are  formally  defined  as 

Tct.r—  Tinv  bJ  Tint i  where 

Tinv  =  {U  I  (c;-r,  Ci.ti)  E  T  A  3  tj  •  ( Cj.s ,  Cj.tj )  E  T  A  (cj.£,-,  Cj.tj)  E  threadmap} 

Tint  =  {ti  e  (Tall  \  Tiny)  |  3  tj  E  Tinv  •  (U,  tj)  E  interacts +} 

Tall  —  Us,ect.s{^  I  ci- 0  ^ 

interacts  —  {ti,  tj  E  Tan  \  U  ^  tj  A  3  e  •  e  E  (a£;  D  afj)  A  e  ^  (c,.7£  U  c,-.<S)} 


TCj.5  =  Tinv  U  Tin<,  where 

Tinv  —  {tj  I  (cj.5,  Cj.tj)  ET  A  3  ti  •  (c,-.r,  c, -.£,*)  E  T  A  ( C; .  ti ,  .  tj )  E  fftreadmap} 

Tint  =  {ti  E  (Tfln  \  Tint;)  |  3  tj  E  Tjm;  •  (£*,  fj)  E  mferacte4' } 

Ta//  ~  Us.GCj.sO  I  (cs>  siit)  E  T} 

interacts  =  {^,  tj  E  Tau  \  ti  ^  tj  A  3  e  •  e  E  (a^  n  afy)  A  e  ^  (c;.7£  U  Cj.<S)} 

MinGlue(ci.r ,  Cj.s)  =(|||ti  |  (cf.r,c1JI)€TA3tJ»(cJ.sJcJJJ)€TA(ct  Jt,c;  .ij)6«/ireadmap  ^oG(Cj.r,  CjTj))  || 

I  (c1.r,c1.il)GTA(c;.5,cJ.e;)eTA(c>.fl,c;.^)et/ireorfmap  Conn(Ci .r,  C,.^,  Cj.s,  Cj.ij))  || 
(lllij  I  (Cj.5,Cj.f;)6TA3  £,#(c, .r,cI.t1)eTA(cI.tl,Cj.iJ)€</ireadmap  ^ G(Cj.S,  Cj.tj)) 

Note  that  the  specifications  of  T,„t  above  are  not  perfect.  The  form  specified  is  correct  in 
that  it  will  not  leave  out  logical  threads  that  could  interact  with  the  involved  logical  threads. 
But,  it  may  include  logical  threads  that  do  not  interact  with  the  involved  logical  threads. 
Ideally,  a  logical  thread  should  be  included  in  T,n£  only  if  it  contains  an  event  in  its  alphabet 
that  is  also  used  by  a  member  of  Tinv  and  the  two  logical  threads  are  composed  using  a  || 
operator.  Logical  threads  composed  using  the  |||  operator  cannot,  by  definition,  interact,  and 
therefore  should  not  be  retained. 


5.2  Compositional  Minimization:  Reentrant 
Interactions 

Since  reentrant  interactions  always  map  logical  threads  of  the  source  pin’s  component  to 
logical  threads  of  the  sink  pin’s  component  in  a  one-to-one  manner,  we  can  actually  do  away 
with  the  sink  and  source  glues.  All  we  need  is  a  simple  process  connecting  a  source  pin 
directly  to  a  sink  pin,  for  example 

SoG(ci.r)  =  NOTHING 
SoG(ci.r ,  a^)  =  NOTHING 

Conn(ci.r,  Ci.ti.  Cj.s,  Cj.tj)  —  Ci.ti.r  — ►  Cj.tj. s  — »  Cj.tj. s  — »  Ci.tj.r  — »  Conn(ci.r,  Cj.ti,  Cj.s,  Cj . 
SiG(cj.s)  =  NOTHING 
SiG(Cj.s,  Cj.tj)  =  NOTHING 
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As  when  producing  a  restriction  (e.g.,  P'c  |"  T),  the  resulting  CSP  expression  (an  interaction 
composition  or  assembly  composition)  should  be  reduced  using  the  following  rules: 

P  ||  NOTHING  =  P 
P  HI  NOTHING  =  P 

5.3  Compositional  Minimization:  Assemblies 

The  simple  composition  semantics  for  assemblies  given  earlier  can  include  more  information 
than  is  necessary.  For  example,  sink  glues  would  be  included  for  sinks  that  are  not 
stimulated.  We  can  certainly  figure  out  which  sinks  are  not  connected  to  any  sources  and 
exclude  their  behavior,  but  we  can  actually  take  this  idea  a  bit  further.  We  should  also  take 
into  account  which  sinks  can  be  stimulated  by  the  assembly’s  environment. 

We  use  the  set  EnvSinks  to  represent  which  logical  threads  of  which  sink  pins  the 
environment  is  allowed  to  stimulate.  EnvSinks  is  a  set  of  (sink  pin,  logical  thread)  pairs.  The 
value  of  EnvSinks  is  supplied  by  the  component  assembler,  but  must  conform  to  the 
constraint:  EnvSinks  C  T.  That  is,  every  pair  is  well  defined,  also  appearing  in  T,  the  set  of 
allocated  logical  threads  of  the  assembly. 

Given  this  information,  we  can  determine  which  logical  threads  can  be  stimulated  directly  or 
indirectly  within  that  environment.  The  set  of  mappings  between  logical  threads  that  can  be 
stimulated  is  usable ,  which  is  defined  as 

usable  =  {(ct*.^,  Cj.tj)  £  threadmap  \  3{c.s ,  c.t)  £  EnvSinks  •  ((c.t  =  c;.£j)  V 

(c.£,  Ci.tj)  £  threadmap +)) 

That  is,  a  logical  thread  of  a  component  can  be  stimulated  only  if  it  can  be  stimulated 
directly  by  the  environment  or  is  connected  transitively  back  to  a  logical  thread  that  can  be 
stimulated  directly  by  the  environment.  Only  the  subset  of  logical  thread  mappings  from 
threadmap  for  which  the  source  pin’s  logical  thread  can  be  stimulated  is  included  in  usable. 

Using  EnvSinks  and  usable ,  we  define  a  more  compact  Assembly  CSP  process  as 

Assembly  =  Components  {AC)  ||  Source  Glues  {AC)  ||  SinkGlues{AC)  ||  Connections{AC) 

Components{AC)  =  \\\ceAC  P'c  \  Tc 
Tc—  Tinv  U  T{nt 

Tinv  —  {i  |  3  a.tj  •  c.t)  €  usable}  U  {i  |  3p  •  ( c.p ,  c.t)  €  EnvSinks} 

Tint  =  £  (  Tail  \  Tjnv)  |  3  tj  €  T{nv  •  ( ,  tj )  <E  interacts +  } 

Tall  ^IJsecA*  I  (c-s,c.t)  £T} 

interacts  —  tj  £  Tau  |  t{  /  tj  A  3  e  •  e  £  (a^  fl  atj)  A  e  ^  (c.  1Z  U  c.<S)} 

SourceGlues{AC)  =  \\\c.reAusources  SoGlue{c.r) 

AllSources  =  {c.r  \  c  £  AC  A  r  £  c.lZ  A  3  Cj.s  •  (c.r,  Cj.s)  £  top} 

SoGlue{c.r)  =  |||t.  | (c.rjC.tl)^r Aa  Cj.tj»(c.tt,Cj. Reusable  SoG {c.r ,  C.ti) 
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SinkGlues(AC)  =  |llc.»€/lHSi»»to  SiGlue{c.s) 

AllSinks  =  {c.s  |  c  €  j4C  A  s  G  c.S  A  3  cx.r  •  (c,.r,  c.s)  €  top} 

SiGlue(c.s)  =  |||t>  \(c.s,c.tj)eT/\3c%.U*(ct.t%,c.tj)€usable  SiG(c.S,  C.tj) 


Connections(AC)  —  \\\^Ct,r)^AUSources,(cj.s)eAUSinks\(ct.r,crs)etop  Conns(ci.r,  Cj  .s) 

Conns(Ci.r ,  Cj.s)  =  |||i(}£j  I  (c1.r,ct.())€TA(cJ.s,cJ.«J)€rA(cI.ilJcJ.iJ)G«5aWe  Gonn(Ci.r ,  Cj.Jj,  Cj.S,  Cj. 


We  have  restricted  the  composition  to  include  only  behavior  that  can  be  stimulated,  directly 
or  indirectly,  by  the  assembly’s  environment.  This  is  accomplished  using  a  combination  of 
techniques: 


•  usable ,  the  constrained  version  of  threadmap ,  only  contains  mappings 
between  logical  threads  that  can  be  stimulated  in  a  particular  environment, 
as  given  by  EnvSinks.  This  constraint  is  key  to  the  other  restrictions. 

•  The  restriction  P'c  [  Tc  removes  logical  threads  that  cannot  be  stimulated 
from  components’  behavior  descriptions. 

•  The  use  of  usable  in  the  quantified  |||  operators  in  the  definitions  of 
SoGlue(ci.r),  SiGlue(cj.s),  and  Conn(ci.r,  Cj.s)  prevents  glues  and 
connections  from  being  included  for  logical  threads  that  cannot  be 
stimulated  when  the  assembly  is  used  in  a  particular  environment. 


5.4  Compositional  Minimization:  Further 
Optimizations 

The  previous  sections  outlined  some  simple  state-space  minimization  techniques  to  illustrate 
possibilities.  We  are  well  aware  that  many  other  techniques  are  likely  applicable;  this  is  an 
area  we  continue  to  explore. 

There  are  also  more  opportunities  to  simplify  the  CSP  we  have  defined  for  interaction 
semantics.  For  example,  we  are  considering  whether  the  Conn  process  interposed  between 
source  and  sink  glues  is  really  necessary.  If  we  can  handle  the  binding  of  sources’  logical 
threads  to  sinks’  logical  threads  in  sink  glue  processes  (5zGs),  we  should  be  able  to  remove 
Conn  and  reduce  the  size  of  generated  state  spaces  a  bit  more. 

Further  state-space  reduction  would  be  possible  when  we  employ  a  model  checker  to  verify 
such  descriptions.  In  particular,  we  would  like  to  use  well-proven  techniques  such  as 
partial-order  reduction,  assume-guarantee  reasoning,  and  efficient  state-space  representations 
such  as  ordered  binary  decision  diagrams  (OBDDs)  for  verifying  assembly  specifications. 
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6  Examples 


The  following  sections  present  some  simple  examples  to  illustrate  the  semantics  of  CL  that 
have  been  presented. 

6.1  Example  of  Simple  Reentrant  Interaction 

Component  c\  has  two  sinks,  x  and  y\  both  of  which  are  mutex  sinks.  It  has  one  source,  r, 
which  is  a  synchronous  source.  c\.S  =  {a,  y}.  C\.TZ  =  {r}. 

Component  c 2  has  one  sink,  s,  which  is  a  reentrant  sink.  It  has  one  source,  z,  which  is  a 
synchronous  source.  C2-<S  =  {5}.  C2.7£  =  { z }. 

Source  r  is  connected  to  sink  s,  meaning  that  top  =  {(ci.r,  c2.s)}.  A  diagram  showing  this 
assembly  is  shown  in  Figure  10. 


Figure  1 0:  Reentrant  Interaction  c  1 .  r  c2 .  s 


ci  has  two  reactions,  one  for  each  mutex  sink.  Pc,  is  defined  in  terms  of  these  reactions,  as 
follows: 

Pc  1  —  Rx  HI  Ry 

Rx  —  x->r—>r-^x-^Rx 

Ry  =  y  — ►  t  — >  r  y  — >•  Ry 

The  transformed  version  P*Cl  is  easy  to  produce  in  this  case.  There  are  no  reentrant  sinks,  so 
each  reaction  produces  one  logical  thread.  Specifically,  Rx  produces  logical  thread  *i,  and  Ry 
produces  Consequently,  T  for  ci  only  is  equal  to  {(ci.rc,  ci.ii),  (ci.r,  Ci.^i),  {c\.y,  Ci.^), 
(ci.r,  c\.t2)}‘  P'c  1  is  defined  as 

P'C1  =  LTh  HI  LTti 

LTtl  =  Rx[Vp  G  {re,  y,  r}  •  cx  .h.p\p] 

LTt 2  =  Ry  [Vp  G  {x,  y,  r}  •  ci.t2.p\p] 

C2  only  has  one  reaction.  PC2  is  defined  in  terms  of  this  reaction,  as  follows: 

P  C2  —  Rs 

Rs  —  s  — y  z  — y  z  — y  s  — y  Rs 
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However,  in  the  context  of  this  interaction.  C2  has  two  logical  threads  (£3  and  £4),  one  for  each 
logical  thread  in  c2’s  environment  that  can  interact  with  s.  Each  logical  thread  is  a  copy  of 
Rs.  T  for  C2  only  is  equal  to  {(c2-s,  C2-h).  (c2.z,  C2-ts)<  {c2-s.  c2.£4),  (c2.z,  C2>U)j.  The 
transformed  version  P'2  is  defined  as 

P'ci  =W\l\(c2,s,t)eT  LTt 

LTt  =  Rs  [Vp  €  (s,  z}  •  c2.t.p\p) 

The  full  definition  of  T  is  equal  to 

{(ci-z,  Ci.il),  (ci-r,  Ci-ii),  (ci.y,  cx.t2).  (ci.r,  c,.i2).  (c2-s.  c2.t3 ), 

(c2.z,  c2.t3),  (c2.s,  c2.t 4),  (c2.z,  c2.t4 )}. 

There  are  two  possible  definitions  of  threadmap  that  satisfy  the  constraints  identified  earlier, 
and  the  choice  of  allowable  values  is  arbitrary.  For  this  example,  we  define 
threadmap  =  {(ci.£i,  c2.£3),  (ci.£2,  C2-h)}. 

After  filling  in  values  particular  to  this  interaction,  Glue(c\.r,  C2-s)  is 

Glue(c\.r:  C2.s)  =SoG(c\.r)  ||  (Conn(ci.r:  c2.s,  c2.£3)  [||  Conn(c\.r,  ci.£2,  c2.s,  c2.£4))  || 

SiGfa.s) 

The  composed  behavior  of  the  interaction  between  r  and  s  is 
/(cx.r,  c2.s)  =  P9Cl  ||  Glue(c\.r:  c2.s )  ||  P’C2 

Finally,  below  we  re-present  all  of  the  CSP  processes  used  in  defining  the  interaction  between 
C\.r  and  c2-s  after  all  substitutions  and  renaming  have  been  performed: 

/(ci.r,  c2.s)  =  P'Cl  ||  Glue{c\.r ,  c2.s)  ||  P'2 

P'Ci  =  LTh  HI  LTt2 

LTlx  =  c\.t\.x  -4  C\.t\.r  — >  c\.t\.r  -4  ci.ti.x  -4  LTtl 

LTt2  =  c\.t2.y  -4  c\.t2.r  -4  c\.t2.r  -4  Ci-<2-y  -4  LTt2 

P'C2=LTt3\\\LTu 

LTiz  =  c2 .  £3 .  s  ->  c2 .  £3 .  z  c2  • £3  ♦  ^  -►  c2.£3.5  LT(3 

=  C2«£4*S  — >  C2 .  £4  •  >2:  — >  C2.£4.Z  — ^  C2-£4*5  — >  Z/7\j 

G7ite(ci.r,  c2.s)  =  5oG(ci.r)  ||  (Gcmn(ci.r,  ci.£i,  c2.s,  c2.£a)  |||  (7onn(ci.r,  ci.£2,  c2. 5,  c2. £4))  || 
5iG(c2.s) 

5oG(ci.r)  =  5oG(ci.r,  ci.£i)  |||  5oG(ci.r,  ci.£2) 

SoG{c\.r,c\.t\)  —  c\.t\.r  c\.t\.r.left  — >  ci.£i.r./e/£  — »■  ci.£i.r  — ►  SoG(ci.r,  ci.£i) 

5oG(ci.r,  ci.£2)  =  ci.£2.r  — >  ci.£2.r.Ze/£  — >  C1.t2-r.left  —>  ci.£2.r  — >  SoG(c \-r,c\.t2) 


Conn(c\.r%  c\.t\,C2-s,C2'h)  =  c\.t\.r.left  -*  C2-h-s. right  -»  C2-h.s. right  — >  c\.t\.r.left  — ► 
Gorz7z(ci.r,  ci.£i,  c2.s,  c2.£3) 

Gonn(ci.r,  ci.£2,  c2.5,  c2.£4)  =  c\.t2-r.left  —¥  c2-U.s.right  — >  c2-U.s.right  — >  c\.t2.r.left  — > 
Conn(c\.r.  c\.t2^  c2.s,  c2.£4) 
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SiG(c2.s)  =  SiG(c2-s,  c2>h)  |||  SiG(c2.s,  c2.f4) 

SiG(c2.s<  c2.ts)  =  c2.t^,s.right  — f  c2.tz.s  — ►  c2.h-s  c2.t^.s. right  -»  5i(?(c2.s,  c2.fe) 

5iG(c2.s,  c2 .  £4 )  =  c2.^. 5. right  — >  c2.^.5  — c2.£4.s  — >  c2-U.s.right  — >  5iG(c2.$,  c2.^) 

6.2  Example  of  Simple  Mutex  Interaction 

Component  ci  has  two  sinks,  £  and  y:  both  of  which  are  mutex  sinks.  It  has  one  source,  r, 
which  is  a  synchronous  source.  ci.S  =  {a:,  y}.  c\.TZ  =  {r}. 

Component  c2  has  one  sink,  s,  which  is  a  mutex  sink.  It  has  one  source,  z,  which  is  a 
synchronous  source.  c2.<S  =  {s}.  c2.H  =  {z}. 

Source  r  is  connected  to  sink  5,  meaning  that  top  =  {(ci.r,  c2.s)}.  A  diagram  showing  this 
assembly  is  shown  in  Figure  11. 


Figure  1 1:  Mutex  Interaction  c\.r  ^  c2.s 


Ci  has  two  reactions,  one  for  each  mutex  sink.  PCl  is  defined  in  terms  of  these  reactions,  as 
follows: 

P c\  =  Rx  III  Ry 

A  2;  —  x  — ^  r  — y  r  — y  x  — y  Rx 
Ry  =  y  —y  r  —±r—yy—y  Ry 

The  transformed  version  PfCl  is  easy  to  produce;  since  there  are  no  reentrant  sink  pins,  each 
reaction  produces  one  logical  thread.  Specifically,  Rx  produces  logical  thread  t\,  and  Ry 
produces  t2.  Consequently,  T  for  ci  only  is  equal  to  {(cj.x,  c\.t\),  (ci.r,  ci.ti),  (ci.y,  ci.£2), 
(ci.r,  C\.t2)}.  PfCl  is  defined  as 

P'Ci  =  LTh  HI  LTh 

LTtl  =  Rx[Vp  €  {x,y,r}  •  ci.ti.p\p] 

LTh  =  Ry  \ip  €  {x,  y,  r}  •  ci.t2.p\p] 

c2  has  only  one  reaction,  that  for  its  mutex  sink.  PC2  is  defined  in  terms  of  this  reaction  as 
follows: 

P  C2  =  Rs 

Rs  =  s  — y  z  — y  z  — y  s  — y  Rs 

The  transformed  version  P*c  is  also  easy  to  produce;  since  its  sink  is  not  a  reentrant  sink,  its 
reaction  produces  one  logical  thread,  1 3.  T  for  c2  only  is  equal  to  {(c2.s,  ^.£3),  (c2.z,  ^.£3)}. 
F'2  is  defined  as 
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P'c2  =  LTh 

LTh  =  Rs[Vp  e  {s,  zj  •  c2.t3.p\p] 

The  full  definition  of  T  is  equal  to  {(ci.x,  (ci.r.  ci.fi),  (c\.y.  C\.t2),  {c\.r,  C\.t2), 

{c2.s,  c2.t3),  (c2.z,  c2.t3)}. 

There  is  only  one  definition  of  threadmap  that  satisfies  the  constraints  identified  earlier: 
threadmap  =  c2.fe)5  (ci.fe,  C2.fe)}- 

After  filling  in  values  particular  to  this  interaction.  Glue{c\.r,  C2-s)  is 

Glue(c\.r,  C2.s)  =  SoG{c\.r)  ||  ( Conn(c\.r ,  c\.t\,  C2*s,  C2-fe)  |||  CVmn(ci.r,  C2.S,  02^3))  | 
5iG(c2.5) 

The  composed  behavior  of  the  interaction  between  r  and  5  is 
I(cvr,c2.s)  =  P'C1  ||  Glue{c\.r ,  c2.s)  ||  P'C2 

Finally,  below  we  re-present  all  of  the  CSP  processes  used  in  defining  the  interaction  between 
r  and  s  after  all  substitutions  and  renaming  have  been  performed: 

I{ci.r,c2.s)  =  P'C1  ||  Glue(c\.r ,  c2.s)  ||  P', 

P'cl=LTtl\\\LTt2 

LTtl  —  — y  c\.t\.v  — y  c\.t\.r  — y  c\.t\.x  — y  LTti 

LTt2  =  c\.t,2>y  —y  C\.t2>r  —y  c\.t2.r  —y  c\.t2-y  — >•  LTt2 

P'C2  =  LTt3 

LTt3  =  C2-h>s  —y  C2-t^.z  —y  C2.i3.-z  — >  c2-t^.s  — y  LTi3 

Glue(ci>r,  C2-s)  =SoG(c\.r)  ||  (Connfa.r,  c\.t\,  C2-S,  C2-h)  |||  Conn(c\.r,  c\ ^  C2.S,  ^.<3))  II 
SiG(c2-s) 

SoG(ci.r)  =  SoG{c\.r,  c\.ti)  |||  SoG(c\.r,  c\ .t2) 

SoG(c\.r,  c\.t\)  =  c\.t\.r  — y  c\.t\.r.left  — »  c\.t\.r.left  — >  ci.ii.r  — >  5oG(ci.r, 

Sh(j(ci.r,  ci.^)  =  Ci.i2-r  — ►  C1.t2-r.left  —y  c\.t2-r.left  -4  ci.i2*r  -4  SoG(ci.r,  ci-fe) 

Conn(ci.r,  c\ .t\,  C2.S,  C2-t^)  =  c\.t\.r.left  —y  c\.t\.r  .right  —y  c\.t\.r  .right  —y  c\.t\.r.left  —y 

Conn[c\.r ,  ci.ii,  C2.S,  C2.fe) 

C,onn(ci.r,  ci.^2?  C2.5,  02.^3)  =  c\.t2.r.left  ->  C\.t2*r  .right  — »  c\.t2-r. right  -4  C\.t2-r.left  — > 

CoTlf^Ci.r,  Ci^2,  ^2.5,  C2-fe) 

£2(7(02. s)  =  5iG(c2.5j  02-^3) 

5zG(c2.5,  C2.fe)  =  lTa2fi?^/li(c2.5,  C2.^)<> 

C2 •  £3 ) < >  —  n  ,  ,  Ci?ij!r!rig/zi  — >  C2-h.s  -4 

c,  .rt  { ci  .r } 

WaitRight(c2.s ,  c2.t3)<Ci.tl.r> 

WaitRight{c2.s,c2.t3)  =  (□  a? U'.r'.right  -> 

<2  <x.y.z>  ct.rkz\c\  .r) 

WaitRight{c2.s,'c2.t3)  ^  ^  ) 

<c,.t,.r>  Q  <x.y.z> 


38 


CMU/SEI-2002-TN-026 


Oc2.t3.s  — >•  x.y.z.right  -¥  Nextfa.s,  C2-tz)Q 

Next(c2-s,  C2 •  ^3 ) < >  =  WaitRight(c2-s ,  C2-<3)<> 

Next(c2.s,c2.t 3)  ^  -c2.t3.s  ->  WaitRight(c2.s,c2.t3)  ^ 

Q  <x.y.z>  Q  <x.y.z> 

6.3  Example  of  Simple  Assembly 

The  example,  shown  in  Figure  12,  presents  the  modeling  of  a  real-life  scenario  in  Pin.  The 
software  assembly  consists  of  two  GUIs,  G\  and  G2,  operating  on  different  client  machines 
that  need  the  services  of  database  server  D,  statistical  library  5,  and  printer  P.  In  order  to 
complete  its  job,  a  GUI  component  gets  data  from  D  (e.g.,  a  list  of  a  firm’s  employees  and 
their  salaries  or  stock  indexes  over  a  period),  uses  functions  from  S  to  process  it  (mean, 
correlation),  and  sends  the  results  to  printer  P. 


Figure  12:  Simple  Assembly 


G\  and  G2  represent  GUI  components,  D  represents  the  Database  server,  S  represents  the 
statistical  library  component,  and  P  represents  the  printer  component. 

The  component  specifications  are 

Pa,  =  Rg 
P  G2  =  Rg 

Rg  =  gt  — »  gd  gd  — >  gs  ->  gs  — ►  gp  —>  gt  -»  Rg 


Pd  —  Pd 

Rd  =  d  — >  pdint  d  Rd  (where  paint  corresponds  to  internal  processing) 


Ps  =  Rs 

Rs  =  s  —*  psint  — ►  s  — »  iZs  (where  psint  corresponds  to  internal  processing) 
Pp  = 

Rp  —  p  ppint  ->  Rp  (where  corresponds  to  internal  processing) 
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T  —  {(G^.gt,  G\.ti),  ( Gi  .gs.  G\.t\).  (G\ .gd.  G\.ti).  (G\ . gp ,  G\.t\),(G2.gt,  G2-t2). 

(G2gs,  G2 -t2),  (G2.gd,  G2.t 2)1  (G2 -9P-.  G2-t2),  {D.d,  D.t3),  ( P-p ,  P.t 4),  (S.s,  S.t 5), 
{S.8,S.tt)} 

The  transformed  processes  are 

P'Gl  =  LTt> 

LTh  =  Rg[Vp  €  {gt,gd,gs,gp}  •  Gi.ti.p\p] 


P'g2  =  LTt2 

LTt2  =  Rg [V p  G  {gt,  gd,  gs,  gp}  •  G2.t2.p\p] 

P'd  =  LTt3 

LTh  =  Rd[Vp  €  {d}  •  D.t3.p\p,V  e  G  {pdint}  •  D.e\e ] 


P'p  =  LTt, 

LTU  =  RP[V  g  €  {p}  •  P.U.q\q,y  e  €  {ppint}  •  P.e\e] 

P's  =  LTts  HI  LTt6 

LTk  =  Rs[Vp  G  {s}  •  S.t3.p\p,\/  e  G  {/w}  •  5.e\e] 

LTk  =  Rs[Vp  G  {s}  •  S.te.p\Pye  G  {psint}  •  5.e\e] 

threadmap  =  {(Gu.tj,  D.t3),  (G2.t2,  D.t3),  (G\.t\,  P.t 4),  (G2.t2.  P-tg).  S.t 5), 

(G2.t2,  S.t$)} 

AC  =  {GuG2.D,S,P} 

Assembly  =  Components(AC)  ||  SourceGlues(AC)  ||  SinkGlues(AC)  ||  Connections(AC) 
Components(AC)  =  P'Gl  |||  P'Gi  |||  P'D  |||  P's  |||  P'p 

SourceGlues(AC)  =  SoGiGx.gd)  |||  SoGiGx.gs)  |||  SoG{Gi.gp)  |||  SoG{G2-gd)  ||| 

SoG(G2.gs)  HI  SoG(G2.gp) 

SoG{G\.gd)  —  SoG(G\.gd ,  Gi.ti)  using  the  mutex  SoG 

SoG[ G’i .gs)  =  SoG ( G'i .gs.  G\.t\)  using  the  reentrant  SoG 

SoG(G\.gp)  =  SoG(G\.gp ,  Gfi.<i)  using  the  asynchronous  SoG 

SoG(G2-gd)  =  SoG(G2.gd ,  G2-t2)  using  the  mutex  SoG 

SoG(G2.gs)  =  SoG(G2.gs ,  G2.t2 )  using  the  reentrant  5'o G 

SoG(G2.gp)  —  SoG(G2.gp,  G2-t2)  using  the  asynchronous  SoG 


SinkGlues(AC)  =  SiG(Gx.gt)  |||  SiG{G2.gt)  |||  SiG{D.d)  |||  SiG{S.s)  |||  SiG{P.p) 
SiG(G\.gt)  —  SiG(G\.gt ,  Gi.ti)  using  the  mutex  SiG 

SiG(G2.gt)  =  SiG(G2.gt,  G2.t2)  using  the  mutex  SiG 

SiG(D.d)  =  SiG(D.d,  D.t3)  using  the  mutex  SiG 

SiG(S.s)  =  SiG(S .s,  S .t$)  |||  SiG(S.s.S.t^)  using  the  reentrant  SiG 

SiG(P.p)  =  SiG(P.p,  P.tg)  using  the  asynchronous  SiG 


Connections  (AC)  =  Conns(G\.gd.D  .d)  |||  Conns(G2.gd.  D.d)  |||  Conns(G\.gs,  S  .s)  ||| 
Conns(G2.gs,  S.s)  |||  Conns(G\.gp,  P.p)  |||  Conns(G2.gp,  P-p) 
Conns(G\.gd.  D.d)  =  Conn(G\.gd.G\.t\.D.d,D.t3)  using  the  mutex  Conn 
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Conns{G2- gd,  D.d)  =  Conn(G2-gd<  G2-t2,D.d<D.t$) 
Conns{G\.gs,  S.s)  =  Conn(Gi.gs,  G\.t\,  5.5,  S.t5) 
Conns(G2-gS,  S.s)  =  (7072T2((?2.£5,  G2^2,  5-«S,  5.%) 
Conns(Gi.gp,  P.p)  =  Conn(Gi.gp,  G\.ti,  P.p,  PA4) 
Conns{G2'gp,P>p)  =  Conn(G2-gp,  i°*p,  PM) 


using  the  mutex  Conn 
using  the  reentrant  Conn 
using  the  reentrant  Conn 
using  the  asynchronous  Conn 
using  the  asynchronous  Conn 
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7  Open  Issues 


There  are  a  number  of  topics  we  need  to  address  before  completing  CL.  We  are  currently 
working  on  refining  our  representation  of  pin  events,  describing  environments,  defining  the 
relation  between  assemblies  and  environments,  hiding  internal  behavior,  and  defining  all  the 
details  of  the  CL  language. 

7.1  Representing  Pin  Events 

Currently,  activity  on  a  pin  is  denoted  by  a  CSP  event  of  the  same  name,  and  each 
interaction  on  a  pin  is  denoted  by  a  pair  of  such  events,  one  for  the  initiation  of  the 
interaction  and  one  for  the  completion  of  the  interaction.  Unfortunately,  this  simple  approach 
leads  to  difficulty  in  correctly  expressing  some  behaviors  because  the  events  are  ambiguous. 
Ideally,  initiation  and  completion  of  an  interaction  on  a  pin  should  be  distinct  events. 

We  are  considering  options  for  distinguishing  these  events.  One  option,  similar  to  that  used 
in  CCS  [Milner  89]  and  Wright  [Allen  97],  is  to  use  event  pairs  such  as  e  and  e.  However, 
while  CCS  and  Wright  use  event  pairs  to  differentiate  initiating  and  observing  a  synchronized 
event,  we  want  to  distinguish  between  initiating  and  completing  an  activity,  as  represented 
by  a  pair  of  related  events.  Since  this  is  a  different  kind  of  distinction,  we  are  considering 
other,  similar  syntactic  conventions  to  avoid  confusing  anyone  familiar  with  those  languages. 

Such  a  distinction  is  not  just  a  syntactic  aid  to  the  reader.  Some  of  our  glue  definitions,  such 
as  SiG  for  mutex  interactions,  are  subtly  incorrect  in  their  current  form,  because  we  cannot 
distinguish  initiation  from  completion  events.  There  are  alternative  ways  to  correct  these 
definitions,  but  making  the  proper  distinction  on  pin  events  is  the  simplest  option  and  also 
improves  the  readability  of  CL  specifications. 

7.2  Describing  Environments 

In  Section  3,  we  mentioned  that  assemblies  are  defined  in  the  context  of  some  environment 
and  that  this  environment  affects  the  behavior  of  the  assembly.  An  environment  defines  the 
semantics  of  the  connectors  used  in  the  assembly  and  provides  services  (such  as  a  clock)  to 
the  assembly. 

An  environment  is  also  the  boundary  through  which  components  interact  with  things  not  in 
the  assembly.  In  the  current  CSP  semantics,  this  aspect  of  an  environment  is  not  well 
specified.  To  analyze  an  assembly,  we  should  define  how  components  interact  with  the 
environment  of  their  assembly. 

In  particular,  four  questions  stand  out: 

•  Which  sinks  are  exposed  to  the  environment?  For  those  sink  that  are  not 
exposed  and  that  do  not  interact  with  sources  within  the  assembly,  we 
should  exclude  their  behavior  from  the  analysis  model.  One  solution  to 
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prevent  behavior  from  unconnected  sink  s  would  be  to  place  the  assembly 
process  in  ||  with  Stops. 

•  What  is  the  potential  concurrency  in  the  environment  with  respect  to  an 
exposed  sink?  Can  multiple  threads  in  the  environment  interact  with  the 
same  sink  concurrently?  We  have  sketched  a  solution  to  this  concern  in 
Section  5.3  with  EnvSinks ,  but  we  have  no  threadmap  equivalent. 

•  What  types  of  interactions  exist  between  an  environment  and  sinks?  Are 
they  the  same  types  of  interactions  that  exist  within  an  assembly?  If  so,  we 
need  to  model  them  explicitly.  In  the  current  minimized  semantics  for 
assemblies,  we  do  not  include  sink  glue  processes  for  sinks  connected  only 
to  the  environment:  this  may  change. 

•  What  can  be  assumed  regarding  how  an  environment  will  behave?  Is  the 
behavior  of  an  environment  unconstrained?  If  so,  we  could  model  that  with 
an  explicit  Run  process,  or  we  could  leave  the  environment  unspecified  as 

it  is  now.  Is  the  environment  required  to  follow  some  protocol?  If  so,  and  if 
we  want  to  gather  analysis  results  only  for  scenarios  in  which  the 
environment  correctly  follows  the  protocol,  the  environment's  behavior 
must  be  given  an  explicit  CSP  definition. 

The  next  steps  will  be  to  better  define  what  we  mean  by  an  environment  and  to  provide  a 
scheme  for  formalizing  the  semantics  of  environments. 

7.3  Relating  Assemblies  and  Environments 

Assemblies,  runtime  environments  (containers),  environment  types,  and  deployable 
assemblies  are  interrelated  terms  whose  meanings  are  still  under  consideration.  At  one  point 
in  this  report,  we  state  that  an  assembly  is  a  scope  for  components.  Likewise,  an  assembly  is 
associated  with  an  environment  type.  But  are  these  really  the  correct  distinctions?  What 
happens  in  a  case  in  which  subassemblies  share  the  environment  type  of  an  encapsulating 
assembly?  How  many  runtime  environments  are  there  in  such  a  case?  Can  the  subassemblies 
be  deployed  independently? 

We  are  investigating  these  questions.  Some  initial  thoughts  indicate  that  we  may  not  have  all 
the  concepts  separated  correctly.  For  example,  each  assembly  must  be  associated  with  an 
environment  type,  as  that  dictates  the  interaction  semantics  within  the  assembly.  However, 
this  may  not  imply  that  there  is  a  unique  runtime  environment  or  container  associated  with 
each  assembly.  In  a  hierarchy  of  assemblies  of  the  same  environment  type,  only  one  runtime 
environment  of  that  environment  type  may  exist.  Clearly,  any  assembly  that  does  not  have 
its  own  runtime  environment  cannot  be  deployed  independently,  and  so  not  all  assemblies  are 
independently  deployable. 

7.4  Hiding  Internal  Behavior 

Intuitively,  hiding  corresponds  to  abstraction — ignoring  certain  details  and  focusing  on  the 
rest  of  a  model.  In  CSP,  events  can  be  hidden  from  a  process,  resulting  in  a  new  process  with 


44 


C  M  U/S  E I  -2002-TN  -026 


a  smaller  alphabet.  All  hidden  events  are  replaced  by  r’s,  or  internal  transitions,  often 
resulting  in  a  model  whose  state  space  can  be  further  minimized. 

Hiding  has  a  natural  role  in  composition.  Why  not  hide  all  the  internal  activity  of  an 
assembly  and  focus  on  its  externally  visible  behavior?  We  can  hide  all  events  for  pins  that 
are  not  exposed  outside  of  an  assembly  and  get  the  CSP  equivalent.  The  only  question, 
however,  is  what  breaks  if  we  do  this?  By  introducing  non-determinism  (a  natural 
consequence  of  hiding),  will  we  be  producing  analysis  results  that  are  misleading? 

The  next  steps  will  be  to  examine  the  consequences  of  applying  hiding  to  assemblies. 


7.5  Defining  Language  Details 

Throughout  this  report  we  have  shown  excerpts  of  CL  specifications,  but  we  have  not  put  all 
the  pieces  together.  We  have  shown  pin  diagrams  in  which  different  types  of  pins  have 
different  symbols  and  connections  between  pins  are  shown  in  a  certain  way.  We  have  shown 
CSP  specifications  for  reactions,  interactions,  and  assemblies.  But  we  have  not  tied  them 
together  formally. 

One  task  that  remains  is  to  fully  define  CL  and  how  these  pieces  (and  others)  fit  together. 

We  need  a  complete  visual  syntax  for  pin  diagrams,  along  with  rules  for  valid  arrangements 
of  visual  elements  and  to  specify  how  additional  information  is  associated  with  these  visual 
elements.  For  example,  reactions  are  associated  with  components,  and  data  interfaces  are 
associated  with  pins.  We  will  have  a  grammar  for  a  textual  representation  of  this  information 
that  is  suitable  for  machine  processing  and  that  will  likely  include  a  representation  of  the 
information  found  in  pin  diagrams. 
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8  Future  Work 


The  road  ahead  for  predictable  assembly  is  challenging,  even  if  we  limit  our  focus,  as  we  do 
here,  exclusively  to  CL.  Beyond  resolving  the  open  issues  discussed  in  Section  7,  there  are 
several  areas  of  future  development,  some  of  which  must  be  completed  before  we  can  consider 
CL  to  have  a  sound  basis. 


8.1  Specific  Environment  Type  Definition  in  CL 

As  we  have  noted,  the  composition  semantics  we  defined  for  CL  is  relative  to  abstract 
environment  type  E.  A  full  composition  semantics  requires  that  we  define  environment  type 
E*  for  a  concrete  platform.  For  this  purpose,  we  will  use  the  switch- controller  runtime 
described  in  the  PACC  substation  automation  experience  report.4  This  environment  type 
uses  fixed-length  queues  implemented  in  shared  memory  for  intercomponent  communication 
and  provides  a  number  of  runtime  services  for  real-time  computation.  We  will  then  refine  the 
semantics  defined  earlier  with  these  environment-specific  characteristics. 


8.2  Intermediate  Representation 

We  have  defined  a  composition  semantics  in  CSP,  which  would  be  nearly  sufficient  if  our 
intended  analysis  tool  was  restricted  to  just  FDR.  However,  our  target  set  of  analysis  tools 
includes  a  number  of  formal  analysis  systems,  and,  in  addition, 'empirical  analysis  tools  for 
time  (latency)  and  potentially  other  properties.  In  compiler  terms,  we  have  defined  a 
high-level  intermediate  language  for  CL  in  CSP,  but  we  must  still  define  one  (or  more?) 
low-level  intermediate  languages  that  are  suitable  for  machine  processing. 


8.3  Visual  Composition  Tool  Set 

Our  emphasis  on  pure  composition  will  be  most  beneficial  when  we  can  provide  a  visual  tool 
set  for  composing,  analyzing,  and  deploying  component-based  software.  Only  then  can  we 
say  that  we  have  successfully  defined  a  composition  language  and  technology  that  supports 
predictable  assembly.  The  visual  notation  used  in  this  report  provides  a  starting  point  for 
this  work.  Considerable  work  remains,  however,  to  completely  define  the  visual  and  textual 
syntax  needed  to  provide  automated  support  for  composition,  model  generation,  and,  in  the 
long  run,  code  generation. 


4  Hissam,  S.;  Hudak,  J.;  Ivers,  J.;  Klein,  M.;  Larsson,  M.;  Moreno,  G.;  Northrop,  L.;  Plakosh,  D.;  Stafford,  J.; 
Wallnau,  K.;  k  Wood,  W.  Predictable  Assembly  of  Substation  Automation  Systems:  An  Experience  Report. 
Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie  Mellon  University,  to  be  published. 
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Appendix  A  Summary  of  Formal  Notations 
Used  in  This  Report 

A.1  CSP 

We  use  the  following  subset  of  CSP  in  this  paper:5 

•  processes  and  events:  A  process  describes  an  entity  that  can  engage  in 
communication  events.  Events  may  be  primitive,  or  they  can  have 
associated  data  (as  in  elx  and  e\x,  representing  input  and  output  data, 
respectively). 

•  prefixing:  A  process  that  engages  in  event  e  and  then  becomes  process  P 
is  denoted  e  —>  P. 

•  external  choice:  A  process  that  can  behave  like  P  or  Q,  where  the  choice 
is  made  by  the  environment,  is  denoted  P  □  Q.  (“Environment”  refers  to 
the  other  processes  that  interact  with  the  process.) 

•  non-deterministic  choice:  A  process  that  can  behave  like  P  or  Q ,  where 
the  choice  is  made  (non-deterministically)  by  the  process  itself,  is  denoted 

P  n  Q. 

•  alphabet:  The  alphabet  of  process  P  is  the  set  of  events  in  which  the 
process  can  engage  and  is  denoted  aP. 

•  parallel  composition:  Processes  can  be  composed  using  the  ||  operator. 

Parallel  processes  may  interact  by  jointly  (synchronously)  engaging  in 
events  that  lie  within  the  intersection  of  their  alphabets.  Conversely,  if 
event  e  is  in  aP\  and  aP2,  then  Pi  can  engage  in  the  event  only  if  P2  can 
also.  That  is,  process  Pi  ||  P2  is  one  whose  behavior  is  permitted  by  both 
Pi  and  P2. 

•  interleaving:  Processes  can  also  be  composed  using  the  |||  operator. 

Interleaved  processes  never  interact,  even  on  events  that  lie  within  the 
intersection  of  their  alphabets. 

•  sequential  composition:  A  process  that  behaves  like  P,  until  P 
terminates  (Skip)  and  then  behaves  like  Q,  is  denoted  P  ;  Q. 

•  renaming:  Processes  can  be  renamed  in  two  ways.  The  expression  x:P 
represents  a  renamed  process  in  which  every  event  in  P  is  now  prefixed 
with  x.  For  example,  if  P  =  a  ->  6  -»  P,  then  x  :P  =  x.a  — >  x.b  — >  x:P. 

The  expression  P[x.a\a,  x.b\b]  represents  a  renamed  process  in  which  all 
occurrences  of  a  are  replaced  with  x.a ,  and  all  occurrences  of  b  are 
replaced  with  x.b. 

In  process  expressions  — »  associates  to  the  right  and  binds  tighter  than  □.  So 

e  -*  /  — »  P  □  g  Q  is  equivalent  to  (e  — >  (f  -4  P))  □  (g  — »  Q). 

5  Much  of  this  CSP  primer  is  borrowed  or  adapted  from  Allen  and  associates  [Allen  98]. 
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A.2  Formal  Logic 

Logic 

A  A  B  A  and  B 

AVB  A  or  B 

-*A  not  A 

A  =>  B  A  implies  B 

V x  E  S  •  P(x)  universal  quantification  (P(x)  is  true  of  all  x  in  S ) 

3x  €  S  •  P{x)  existential  quantification  (P(^)  is  true  for  at  least  one  x  in  S) 

Sets 

0  empty  set 

e  €  S  e  is  an  element  of  S 

S  U  T  set  union 

S  fl  T  set  intersection 

S\T  set  difference 

Ue€T  generalized  union  (the  union  of  all  sets  S€) 

#S  set  cardinality 

{x  €  S  |  P(a:)}  set  comprehension  (the  set  of  all  x  in  S  for  which  P(x)  is  true) 
Sequences 

<>  empty  sequence 

S  ^  T  S  concatenated  with  T 
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